Проблема выглядит так :
таблицы на SQL связаны relationshipами, все с первичными ключами PKId (Identity).
Отображаем через ADO - связываем между собой Master/Detail и в detail надо LockType=ltBatchOptimistic.
При попытке постить мастера - он пытается постить детальные таблицы с FK_Id=null (еще не определен ключ у таблицы-мастера). Как с этим бороться ?
Если пытаюсь запретить контролы перед постом, детальным датасетам насильно присвоить FK_Id, прочитанный из мастера, потом их постить - не записывает почему-то в базу и ошибок не дает.
Насколько я почитал - простого способа нет... Предлагают не пользоваться identity, не пользовать mster/detail, все писать в базу через stored procedure. Маразм какой-то. Может кто-то сталкивался... Или готовые компоненты посоветуете...

Проект - записная книжка, но большая. Формализован для соответствия - таблица + несколько детайл таблиц=форма (мож с детайл формами). Данные все или вводятся ручками в поля или лукапами. Констрейнты все на сервере (и триггеры валидности). Клиент отлично обрабатывает ошибки, возвращаемые сервером. ЗАЧЕМ нам писать тонны кода для ХП, если по идее, я могу просто записать их с клиента ? В чем польза ? Я считал, что ХП существуют для а) бизнес логики, б) ограничения доступа к базам. Ни то ни другое не актуально.
По существу бы чего-нибудь ...

Продукт - на MSDE. Удобно с точки зрения целостности данных, ограничения доступа, скорости разработки, стоимость серверной части - 0руб.
Бизнес логика реализуется с помощью relationships, constraints и триггеров.
На клиенте фактически только SELECT * FROM таблица в TADOTable указывается.
Зачем нам к каждой из тридцати таблиц (а будет больше) писать процедуры тупой записи в таблицу ?

Попутно встал такой вот вопрос - @@IDENTITY по BOL работает в текущей сессии. Я после вставки записи в новом TADOCommand вызываю SELECT @@IDENTITY, получаю NULL. Почему бы это ??

С select это верно... мы TADODataset используем.
Но вопрос с @@IDENTITY актуален, т.к. разве может другая сессия быть в том же коннекте ? А если бы нормально сработало, то получилось бы прям замечательно :-) Задам ка я этот вопрос еще на SQL форуме :-)

2Александр Спелицин:
>>Зачем нам к каждой из тридцати таблиц (а будет больше) писать процедуры тупой записи в таблицу ?
>Потому что потом у Вас встанет вопрос по безопасности. И Вам придется делать какие-то предварительные проверки перед изменением данных

В общем случае (особенно если проект - корпоративный) - согласен. В моем - это лишняя трата времени. Безопасность, обеспечиваемая аутентификацией пользователей здесь вполне достаточна, да к тому же более важно, например, что машина с базой (с сервером) доступна всем в любое время... Но это - не мои головные боли...

>И Вам придется делать какие-то предварительные проверки перед изменением данных.

Не понял... Если Вы про то, что будут проверки в процедурах - значит в моем случае будут введены триггеры INSTEAD OF, но это не относится к безопасности, а только к бизнес-логике.

>А вот после каждой DML команды также рекомендуется делать всевозможные проверки.

Проверки делаются сервером и генерируются исключения при ошибках, но дело не в этом. Записи нормально вставляются, увеличивая identity. Скорее, прав Dankov (в SQL форуме) про открытие новой сессии, пойду отрабатывать его версию...

Фу-х, наконец-то добил проблему, попутно узнав массу интересного про возможности АДО :-)\r
Если интересно, см. сюда.\r
А то, насоветовали, понимашь...

2Добрый:
Да уж годы не сильно маленькие, тридцатник за плечами...
Но учиться надо всю жизнь. :-)

2Добрый:
>>все писать в базу через stored procedure. Маразм какой-то

Да. В моем случае маразм. Объясню еще раз, почему было такое решение. Потому что невозможно провести полноценное бизнес-обследование, получить готовое ТЗ и т.д. Процесс идет итерациями, структура отдельно взятого участка базы меняется примерно два раза до того, как удовлетворит заказчика (практически прототипирование на лету приходится делать). Введение ХП 1) очень усложнит модификацию базы (минимум в два раза), 2) не несет пока что никакой смысловой нагрузки. Следовательно : МАРАЗМ!!!
Если Вы привыкли всегда все данные писать через ХП - ради бога. Но поверьте, проекты бывают разные. Не поверили? Да и ладно...

>и поносить Delphi (VCL), не умея с ней работать

VCL я поносил по поводу DB контролов. Абсолютно аргументированно. Не отступлюсь! Причем ПОСЛЕ того, как выучил данный участок и сделал решение на его базе. По поводу ADODataset - вроде не ругался конкретно до выяснения обстоятельств... ну, виновато АДО оказалось и аккуратность кодера, Borland получает '+', MS и кодер по '-'. Вроде поносить больше некого. Будут еще комментарии ?

Даже если бы я всю жизнь только на одном VCL программил бы, то все равно учиться бы пришлось до сих пор - вот Delphi .NET выходит, MS Windows 2003, Reporting Services готовится... Не зная системы, ее архитектуры, служб, приложений третьих фирм, невозможно быть хорошим разработчиком/менеджером проекта. Я знаю, что я знаю мало, и я стараюсь все время учиться.

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

В клиенте у нас, как правило, используются выборки SELECT * FROM Table1. С ХП я так же не смогу написать, надо будет явно указывать список полей. У меня все действия с таблицей происходят "автоматом" через компоненты и АДО. А с ХП мне надо отдельно расписывать эти действия (INS/UPD/DEL) При изменении/добавлении полей, надо будет менять их и в процедурах и в клиенте. Зачем мне здесь "третий слой", противником которого Вы, tygra, помнится, выступали ? :-)

>>В клиенте у нас, как правило, используются выборки SELECT * FROM Table1. С ХП я так же не смогу написать, надо будет явно указывать список полей.
>Это кто такое сказал? Как хочешь, так и пишешь. Нужны все поля - пиши *.

В клиенте-то напишу. А в ХП-то поля перечислять придется.

>>У меня все действия с таблицей происходят "автоматом" через компоненты и АДО. А с ХП мне надо отдельно расписывать эти действия (INS/UPD/DEL)
>Один раз сделать механику - компонент типа TUpdateSQL или так - и все. У нас раньше были бащовые формы с компонентами под действия изменения/удаления, теперь компонент. В общем, проблем нет, зато стандартно и просто. А автоматом - это не хорошо. Лучше все контролировать самому, чем полагаться на закрытый механизм.

Такие dataset'ы для Delphi есть на torry, хотя это ухудшение надежности работы IMHO, ошибиться в четырех SQL выражениях проще, чем в одном. Я имел в виду опять же ХП, которые надо писать и переписывать. А для чего ? Просто патаму чта ?

>Да нет тут никакого слоя - а в запросе, который в клиенте, не надо список полей менять? Надо. И в компонент добавлять поля - в ADODataSet - надо. Или у вас динамический список полей? Ну уж это никак.....

Открыть форму, правый click,левый click,Ctrl+A,правый click, левый click, правый click, левый click, левый click, левый click. Итого 8 кликов и одна пара клавиш. Это процедура обновления полей в датасете. Ну, еще и контролы надо, конечно, но в общем, все это придется в любом случае делать, хоть с ХП, хоть без. А тут еще где-то видел автоматическое обновление списка полей при активизации dataset... Надо бы поискать еще раз, может пригодиться (это прям ща идею навеяло)...
Проектные подходы должны упрощать решение, а никак не наоборот...
Да, и улучшения обещаны все такие, которые проекту пока что - как козе баян :-)