очень сильно похоже, что нужен реквери для подчиненной формы.
По сценарию (Б) ОТСУТСТВУЕТ внешний по отношению к рекордсету (подчиненной) формы Update таблицы, по сценарию (А) он ЕСТЬ.

отвечал на самое первое сообщение

по этому обрывку судить вполне тяжело.
когда писал, подразумевал следующее

0) я в АДП прктически как номер этого пункта. Когда-то, когда токо вышел 2000 акс чуть щупнул ад с скль 7 потом повода не было.
(кажется сильно хочу поменять работу, только невдомек как это вообще делается...)

1) тогда (по памяти) увидел, что акцесс норовит с рекордсетами формы работать фактически через глобальные серверные курсоры.

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

3) изменения, проведенные во внешних процессах, и затрагивающие отобранные курсором записи фактически инвалидируют их (Ё уровень изоляции)

4) sp_executesql КАК РАЗ И ЗАПУСКАЕТ такое независимое исполнение.

2 zz
думаю, сохранение НЕ ПОМОЖЕТ, потому как при ДОбавлении меняетсо КОЛИЧЕСТВО подчиненных записей, в которых sp МАРАЕТ при изменении количества и НЕ МАРАЕТ в противном случае.

ЕСЛИ ЭТО ОНО (у тебя НЕ ОБЯЗАТЕЛЬНО оно, мне просто показалось, что похоже) то обходиться можно попробовать 3-мя способами - субъективные мнения в скобках

0) забабахать явный реквери при входе в подчиненную, можно при этом переменную состояния завесть, на которую и смотреть, нужен реквери или нет (чистый акцессный путь )

1) (не нравится) воткнуть явный Update подчиненных в триггер (афтер) НА ВСТАВКУ в подчиненные

2) добавление вынести в собственную хранимку, по возможности избавившись от sp_executesql, иначе, боюсь, все повториться - тут лучше к соседям- скульникам сходить

3) забыл - отвлекли - не могу вспонить - наверно больше ничего не придумаю

2 Саныч

написал 2) полностью, поставил 3) вспомнил про 0) - записал - ОТВЛЕКЛИ - что писать в 3) не помню - может и не было ничего.
-)))))))

вот еще придумалось (не 3 3 должно было бы быть что-то специфически "серверное")

4) (вариация на тему 0 ) переменную состояния забабахать в подчиненной форме, если взведена, то при выходе сначала забабахать простой апдейт на текущем коннекте (без хранимки) И ПЕРЕД ПОТЕРЕЙ ФОКУСА контролом подчиненки - реквери

5) нарисовать "традиционный" цикл изменения на рекордсете

ЗЫ
Не забыть при этом, что в адп я 0 и палоччков у мене нету.

автор автор
1) (не нравится) воткнуть явный Update подчиненных в триггер (афтер) НА ВСТАВКУ в подчиненные


Зачем? Что при этом произойдет?

предварительное замечание
Все что было написано - это не замена реквери, а некоторая его обертка, которая, возможно, при каких-то вариантах рекордсета его (реквери) в клиентском коде не потребует

ответ
Думал вот о чем: Задача произвести update во всех подчиненных при добавлении новых и не производить в противном случае. Умеренно естественным местом для такого действия будет триггер на вставку. (на самом деле не уверен, что он должен быть after - посмотри в BOL) Так ты всю "бизнес-логику" этого вопроса выносиш на сервер, ассоциируешь ее непосредственно с таблицей, и она не интерферирует с простым изменением записи подчиненной таблицы.

Вообще говоря это не отменяет реквери - но есть надежда.



автор автор
2) добавление вынести в собственную хранимку, по возможности избавившись от sp_executesql, иначе, боюсь, все повториться - тут лучше к соседям- скульникам сходить


Добавление записи в подчиненную хранимкой? Это как?

обычная хранимка с параметрами, внутри которой INSERT
тоже ничего не отменяет - см 12:45.
В действительности не знаю, как прикрутить к табличной форме.
При работе с актив-иксами - относительно стандарный способ.

2 Geo
сам я, наверно, пошел бы по дороге 4)

авторА почему вообще происходила ошибка?
все что я думал по этому поводу, изложил в 12:45

ТАМ ОТВЕТ КАК МИНИМУМ НЕ ПОЛНЫЙ, А, МОЖЕТ И СОВСЕМ НЕВЕРНЫЙ.

Еще раз, грубо идея в том, что после updatet-a значений существующих записей вызванных добавлением новой строки в текущем рекордсете ВСЕ СТРОКИ НЕПРАВИЛЬНЫЕ И НЕ СООТВЕТСТВУЮТ текущему состоянию базы данных, о чем адо и пытается сообщить по своему.

ЗЫ1 вот как-то я призывал Latuk-а поспорить - не захотел. А тема-то родственная. (Там тема про остатки-обороты была)
РОДСТВЕННАЯ ТЕМА:Хранение количества штук подчиненных записей в самих подчиненных в отдельном поле.
Я скромно считаю это плохим проектированием, ПРОТИВОРЕЧАЩИМ естественному быту проектирования РЕЛЯЦИОННЫХ базов данных.
В данном случае даже вопиюще. Я бы лишил подчиненные ТАКОГО волшебного знания.

ЗЫ2
авторИ зачем знать перед сохранением изменений в записи @@lastident?
прошу прощения, но я совсем не знаю о чем это - мы об этом никак не говорили и такого в этом потоке не вижу влет. То есть, наверно, не ко мне.