Проблемы - наверняка в настройках 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.
я тоже. Если могу себе это позволить....

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