Перешёл с ODBC+ADO на ZEOS, после чего стали неверно распознаваться типы полей таблицы БД, при добавлении объектов-полей в компоненте ClientDataSet. Например поле, которое в базе данных является автоинкрементным, воспринимается как TIntegerField (чего не происходит когда я работал с ODBC+ADO, там оно интерпретируется как TAutoincField), вследствие чего не прокатывает вставка записи без указания значения этого поля, то есть мне приходится самому задавать значение автоинкрементного поля, что не приемлемо. Аналогично и с другим полем, которое воспринимается нормально (тип "Дата"), но значение требует, хотя в БД явно указано значение по умолчанию (опять же, работало с ODBC+ADO). Раньше, где-то у меня такое возникало, вернее, я этого не замечал и просто задавался вопросом, почему TTable (или TQuery) требовал у меня значение автоинкрементного поля. Кто-нибудь сталкивался с аналогичной проблемой и как её решать?

PostgresSQL 8.2.9
ZeosLib 6.6.4

всё правильно

Добавлено через 1 минуту и 14 секунд
Ты уверен, что у ZeosLib есть автоинкрементные persistent-поля?

Ну допустим,у Zeos'a нету автоинкрементных полей и че теперь, мне самому значение вводить или осуществлять вставку через INSERT?

PS:
Если в запросе INSERT не указывать автоинкрементного поля и соответственно его значения то прокатит!

ну вот так и делай

Зачем тогда спрашивается DB компоненты, я то их использую, жму добавить запись и уже в этой пустой записи устанавливаю значения полей посредством DB компонентов. А в твоем варианте мне придется использовать обычные Edit'ы и считывая с них добавлять информацию в поля записи, не по русски! тебе так не кажется?! И с полем даты, у меня должна вставляться дата серверная (по умолчанию у поля на сервере стоит значение now, то есть текущее время), изначально я планировал вообще не передавать никакого значения при добавлении и в итоге сервер сам поставит значение текущей даты. А в твоем случае мне придется передавать клиентскую дату и чтобы не менялась логика БД лепить триггер и в нем тупо затирать переданную дату на серверную. Я в тексте топика указал, что в ADO через ODBC драйвер все работало прекрасно, то есть и автоинкрементные поля подхватывались и обязательные поля со значением по умолчанию не требовали ввода значения при добавлении записи.

это не означает, что ты или я их обязаны использовать 

Добавлено @ 20:30
Запомни одно очень важное правило: пишущая транзакция должна быть как можно короче по времени.

Теперь представь ситуацию. Ты используешь DBEdit и иже с ним. В этом случае тебе придётся держать пишущую транзакцию пока пользователь заполняет форму добавления/редактирования. А пользователю до одного места твои транзакции и все твои правила. И чем больше ты будешь ограничивать своими правилами заполнения компонентов или форм ввода, тем меньше будут пользоваться твоими программами.
DBEdit больше подходит для работы с файлсерверными СУБД, ака DBE (Paradox, DBF).



Это нормально. При чём здесь по-русски? Вообще как ты предлагаешь, то в жаргоне это называется китайское программирование, типа дёшево и быстро сваять программу и отдать заказчику, а там хоть трава не расти.




Так пусть сервер и заполняет. Вот у Firebird`а есть триггеры на добавление, редактирование записи и т.д. . Вот в этих триггера сам сервер и заполняет, например дату добавления или редактирования. Мало того, есть такое понятие, как значение по-умолчанию. Если серверу не передавать значение поля, то сервер может заполнить его сам.




сделай не тупо, сделай по-умному  
Триггеры для того и придуманы, чтобы делать по-уму, а не ТУПО!!



я читал  
Ничего страшного, зачем тебе ID будущей записи? Я уверен, что в постгре есть способы получить ID будущей записи.

Попробуй сам создать поле типа AutoInc. Будет работать?

Ты смотрел AnyDAC?

Это сообщение отредактировал(а) Akella - 15.2.2009, 20:41

ЭниДак платный! я в своей жизни из ПО тока контр страйк покупал (и то друг платил). Насчет транзакций я в курсе, но у меня трехзвенка, я на этот счет не заморачиваюсь;) А переход с DB компонент на обычные Edit'ы мне добавят геммора (занесение значений полей в Edit'ы при редактировании записи и считывание с них значений для дальнейшего формирования INSERT запроса). Просто в голове не укладывается, как так, в ODBC драйвере который все гноят и ненавидят - все прекрасно! а в Zeos'е с прямым доступом через API и высокой скоростью (в последнем лично убедился)  и такой вещи нету. Я нашел статейку на англоязычном форуме (http://zeos.firmos.at/viewtopic.php?t=1675&postdays=0&postorder=asc&start=0&sid=3d131ad4b20d24a1bb2cec14d0ab670d) на нем кстати можна вырулить на статью где подробно описано как этот бажек исправить, тока косяк в том что речь идет об MySQL а в кодах для PostgreSQL немнога по другому все, руки уже опускаются просто и я забил. Буду наверное сидеть все таки через ADO+ODBC, просто с подгрузкой записей я все таки разобрался (трехзвенная архитектура, топик ещё поднимал недавно) поэтому скорость впринципе меня не волнует, все равно скорость интернет канала у конечных пользователей не будет меньше чем у Zeos'а поэтому скорость загрузки записей не будет так ощутима (тем более я экспериментировал на таблице с числом записей примерно 60000, что далеко от истины в моем случае). Единственный минус что мне придется переходить на Windows хостинг, ибо убунтовский ODBC драйвер не подхватывается моим сервером приложений запущенным под вайном.

ЗЫ:
Меня добивают те факты, что это одна статья на ВЕСЬ интернет, причем именно то о чем я говорил, что не подхватываются значения по дефолту и автоинкрементные поля. Так же поражает что никто и никогда с этим не сталкивался, толи все используют INSERT скрипт толи делают как я, а потом когда у них не получается они делают через INSERT, а самые вумные используют ODBC драйвер. Наверное же не зря есть автоинкрементные поля и значения по умолчанию, которые я указывал при создании БД в PostgreSQL, почему я должен ещё лепить триггеры и вместо программы делать черезжопный вариант, при котором поле будет получать значение, потом триггер его затрет и значение по дефолту у этого поля ваще никогда использоваться не будет.

опять ты невнимателен

Добавлено @ 09:04
UsamaBrainLaden, посмотри сообщение Коваленко Дмитрия (по поводу первичного ключа)
http://www.sql.ru/forum/actualthread.aspx?tid=638316#6814387

Добавлено через 5 минут и 58 секунд
Кстати, почитай доку к постгре, поддерживает ли он


Это сообщение отредактировал(а) Akella - 16.2.2009, 09:04

Предлагаю 2 варианта.
1. Найти и купить компоненты, которые смогут удовлетворить большинство твоих амбиций.
2. Найти разработчика и заказать компоненты специально для тебя, которые удовлетворят ВСЕ твои амбиции.
3. Написать самому компоненты специально для себя.




я рад за тебя  



Напиши свою, правильную, на русском, или лучше несколько. И больше тебя никто добавить не будет.  



да, стараются сделать по-уму



И вообще, купи AnyDAC или используй их бесплатную версию.

Мой дед однажды сказал:"Меньше говори, а больше делай!"
От того что ты пишешь всякую ерунду, толку мало будет. И причем тут амбиции, вполне гуманное требование. Смысловая нагрузка конечно небольшая, но все же есть и ничего криминального в этом нет! А насчет внимательности повторю, что я работаю с трёхзвенной архитектурой и даже если INSERT не возвращает записей, то в компонентах для этой технологии есть соответствующие свойства и методы.

судя по твоим сообщениям - ты не в деда  

Добавлено через 4 минуты и 39 секунд

От твоих возмущений в сторону БЕСПЛАТНЫХ КОМПОНЕНТ, тем более   

Возьми и напиши бесплатные компоненты с хорошей документацией, примерами и статьями. Посмотрим как это у тебя получиться.  




Я тебе тоже повторю. Мне всё равно как ты работаешь. Я тебе говорю о том, что:
1. Есть бесплатная версия AnyDAC, версия 1.х.
2. Функционал, документирование и примеры бесплатной версии AnyDAC превосходит функционал, документирование и примеры ZeosDBO.