Как заколебали эти черно-белые взгляды на мир....
Лучше просто посмотрите здесь

Цитата из приведенной мной ссылки:
>Note: Note the call to ClientDataset.Refresh in the code above. It is used to retrieve the autoinc values with the values that were assigned to the table into the ClientDataset. The TDatasetProvider.Options.poAutoRefresh flag should make the call to Refresh obsolete when it gets implemented. Also, if your database server supports it (e.g. InterBase generators or MS SQL @@identity), you can set DatasetProvider.Options.poPropogateChanges to true and set DeltaDS.FieldByName('ID').NewValue to the new autoinc value in DatasetProvider.BeforeUpdateRecord or DatasetProvider.AfterUpdateRecord. Since we can't accomplish this with a simple one-table Paradox sample, we will use the Refresh method instead. You could also set up a separate key table that keeps track of the IDs assigned to a specific table and use the same technique.
А сам по себе provider конечно не знает, что в датасете что-то изменилось...

2 KirillovA:
Мозги человеку не пудрите, да ?! :-)
ADO возвращает identity на клиента автоматически давным давно - с версии 2.1 по-моему... (У MS есть Q по этому поводу). TADO* также умеет обновлять у себя identity поле (по крайней мере у меня в D7).

Естественно нет - сами-то подумайте - batchupdate есть единая неделимая операция, в т.ч. вставки пачки записей. В этом случае только requery поможет. Но для ХП со вставкой пачки записей тоже надо свой механизм передачи клиенту пачки identity делать...

Естественно, что значение identity получается ADO как SELECT @@IDENTITY, MS в Q-шке об этом так и пишет. Дык если ЭТО уже реализовано, зачем самому ваять то же самое...
А если надо вставлять попутно записи еще в другие таблицы - тогда уж определяться надо - возвращать на место правильный identity в триггере (что IMHO более правильно) или использовать какие-то другие методы (типа ХП).

Зачем чего-то вытаскивать ? Таки вынудили написать код... :-)

Угу. Очередная фенька Багланда, забыл я сразу сказать. Поле IDENTITY в ADOQuery должно быть TIntegerField или еще какое Int, но только не TAutoIncField.

Тэкс. Что значит поле null ? В обработчик ProviderAfterUpdateRecord попадаем или не попадаем ? Что присваивается в обработчике (значение identity правильно ли присвоилось для ADOQuery) ? Как сказано в посте выше poPropagateChanges установлено ?

Проблемы - наверняка в настройках ADOQuery. Должно быть clUseClient, ltOptimistic. Если Delphi5, то не забудьте про ADO Update. Вообще, лучше использовать TBetterADORecordset - там весьма много глюков подправлено...

2 KirillovA:
Исходя из Ваших соображений: чтобы гемора меньше - надо вообще про ублюдочный TADOxx забывать и свой враппер на ADO Recordset делать. А еще лучше через native ODBC :-)
Можно, но сложно...

Так, вспомнил еще одну фишку ....
Provider.ResolvetoDataset должно стоять True, иначе "умная" связка провайдер - TADO... формирует непосредственно запросы на сервер (через ADOCommand). Естественно, в этом случае (ResolvetoDataset=False) все измененные серверной логикой поля должны получаться ручками...
Про BetterADO поищите на форуме.

2 KirillovA:
Написание ХП оправдано в случае, когда безопасность важнее скорости разработки и надежности. В большинстве случаев - это просто разбазаривание времени.
В случае, о котором Вы говорите, необходимо не только формирование строки, но и возврат результата. И для этого свои компоненты надо наследовать и писать. Не проще ли со стандартными разобраться ?

2 KirillovA:
Угу. Строку писать из десятка-трех параметров... identity в рекордсет самому вставлять... Но главное-то не это, а то, что надо еще и ХП рисовать. И так на протяжении всего цикла разработки...
И это вместо 3 стандартных компонент (ADOQuery, DatasetProvider, ClientDataset). Удобненько...

Совершенно согласен по поводу логики, соответственно, если имеем прямой доступ к таблице/view - реализация проверок с помощью триггеров, констрейнтов и т.д. И мой опыт говорит именно об ускорении разработки, когда есть у тебя один-два компонента доступа к данным на клиенте, а логика вся на серваке. И если по три процедуры на каждую таблицу писать - за это заказчик отдельно платить по определенным требованиям должен IMHO.

2 aag:
>Это, уже извините, ерунда какая-то. Давайте забудем про заказчика - то, как вы пишите ващу программу никак не должно зависеть от того, сколько он платит.
Забавно. А я всегда думал, что исходя из оплаты я выбираю реализацию требований (какие делать, а какие отпинывать) и архитектурные подходы (простота/эффективность/безопасность/...)
Как я уже сказал выше - для доп. работы (а я рассматриваю подход с ХП именно как доп. работу, потому как с точки зрения ведения проекта : на 5-и табличках трудоемкость в сравнении с прямым доступом вообще неважна, на 30 уже весьма неприятна, а на 300-заколебешься вести проект) должны присутствовать доп. требования. Эти доп. требования заказчика должны быть оплачены заказчиком.
Стремление "разбираться только со своими багами" на самом деле IMHO пагубно стратегически, поскольку ведет к неиспользованию передовых технологий и, как следствие, отставанию от прогресса :-) Да и просто кругозор надо пошире иметь.

>странные у тебя заказчики, раз изначально хочешь от них быстрее избавица и
сделать только то за что они заплатили ...
Дык и договор о минимизации стоимости :-(

>1. отношение к ним как к ублюдкам которые почемуто мне мало платят хотя типа деньги у них есть а я типа такой пушистый и умный и вижу что мне бабла мало дают.
2. отношение как к нормальным партнерам, с которыми можно иметь дело и в будущем. и поетому делать работу хорошо, пусть трудоемко, но качественно - пусть етого они не видят, но в душе я могу сказать себе, то, что выполнил работу качественно!
Не могу согласиться по одной простой причине - если бы я им впаривал программу, не решающую поставленные задачи, либо работающую с глюками, можно было бы говорить о п.1. Если же я выполняю то, на что договаривались, минимизируя стоимость проекта, претензий со стороны заказчика ко мне нет. А "заделы на будущее" и "на всякий случай" наш бюджет не предусматривает. И так из-за Багланда последнее время работаем в минус.

>я придерживаюсь п.2.
я тоже. Если могу себе это позволить....

>скорость нужна при ловле блох.
надежность нужна всегда.
С годами приходит понимание, что истина всегда находится где-то между крайностями :-)