Vad74Вроде UpdateAll служит для одновременного обновления связанных таблиц, или на добаление записи он не работает?Работает.
Vad74Как тогда правильно добавлять записи в связанные таблицы?"Правильно" - чтобы не нарушались ограничения. В Вашем случае - ссылочная целостность.
Vad74Если можно, выложите пример добавления записей в основную и связанные таблицы.
Или подскажите что я делаю не так в свое тестовом проекте (проект во вложении).У вас мастер-таблица в датасете после сохранения не содержит актуальные значения автоинкрементного первичного ключа, чтобы они могли быть применены в дочерней.

Смотреть тут

IAppleVad74, Почитай книгу "Microsoft ADO.NET", автор Дэвид Сеппа. В ней исключительно подробно и толково расписано.
Я не вижу причин для того, чтобы использовать адаптер для обновлений многих таблиц, а не одной, кроме маниакального стремления запутаться самому и запутать любого, кто заглянет потом внутрь реализации такого адаптера.
Мои советы таковы:
1) делай только адаптеры, которые могут обслужить одну конкретную таблицу (я такие адаптеры создаю при датасете в соответствии с его таблицами)
2) для заполнения датасета создай метод Fill, который будет вызывать последовательно и в нужном тебе порядке методы Fill твоих адаптеров для каждой таблицы датасета, которую необходимо заполнить
3) для связанных обновлений создай для датасета метод Update, который будет вызывать последовательно и в нужном тебе порядке методы Update твоих адаптеров для каждой таблицы датасета, которую необходимо апдейтить"Типизированный" датасет так и работает.
Кроме этого, использование TableAdapterManager.UpdateAll() позволяет не беспокоиться каждый раз при сохранении данных о правильном порядке вызова Update для всех связанных адаптеров.

Но при использовании "типизированных" датсета с конкретно базой access существует проблема с получением обратно в приложение значений автоинкрементных первичных ключей после сохранения данных.

IApplesphinx_mvНо при использовании "типизированных" датсета с конкретно базой access существует проблема с получением обратно в приложение значений автоинкрементных первичных ключей после сохранения данных.
А при использовании "нетипизированных" с конкретно базой access этой проблемы нету ?Адаптеры таблиц, которые создаются в "типизированных" датасетах, НЕ предоставляют доступ к RowUpdated... И для работы "с конкретно базой access" (c) - это, таки, проблема... :)
IAppleМожно Ваш пример реализации адаптера для двух связанных талиц посмотреть ? В смысле как там UpdateCommand выглядит.Я не писал, что "один адаптер создается на несколько таблиц" - я писал про TableAdapterManager , который автоматически создается в дизайнере датасетов и который обрабатывает последовательность вызовов метода Update для адаптеров связанных таблиц.

IAppleVad74, Сеппа для Access советует SELECT @@IDENTITY, которая джолжна б вернуть последнее значение автоинкремента, сгенерированое на данном соединении на пару с использованием события RowUpdating у OleDbDataAdapter.
А что б изменения связанных таблиц в датасете каскадировались "сами" от родительской к дочерней необходимо кроме связей DataRelation в датасете устанавливать связь ForeignKeyConstraint у которого свойство Cascade выставить на Update и Delete.Ниачем... Ваабще...
Потому, что тест-проект ТСа Вы даже не смотрели, а приведеные ссылки не читали - иначе Вам не пришлось бы повторяться в очевидностях.