Народ помогите! 
Ситуация такая: есть база данных MS SQL Server, есть клиентское приложение, которое эту базу юзает, причем с использванием DataSet, никаких хранимых процедур. В этой базе есть две таблицы - одна содержит primary key, а другая соответственно secondary key. 
Так вот, запускаем клиентсоке приложение, добавляем в primary таблицу новую запись (в DataSet добавилась, а в базу еще нет) и создаем новую запись в secondary таблице по id-шнику только что созданной записи. Запускаем одновременно второго клиента и делаем тоже самое. Закрываем обоих клиентов и... Получается что DataSet в обоих клиентах в primary таблице создал разные записи с одинаковыми id-шниками, но в базу данных эти записи записались уже с другими id-шниками. Но в secondary таблице использовалось значение этих id-шников. Получается, что две записи из secondary таблицы будут пренадлежать одной записи из primary таблицы (той что сохранилась на сервере первой), а изначально предпологалось, что будут две пары.
Вот такая вот [censored 6] фигня получается. Дело явно связано с синхронизацией данных. Если кто че знает или может литературки подкитуть, помогите плз.

David Sceppa Microsoft ADO.NET рекомендую.
кстати, гдето валяется и в електронном виде, гдето 73 метра.

Добавлено @ 21:56 
а если в двух словах, после записи в базу, нужно считать созданное id и вписать в датасет, при етом автоматом произаидет замена в подчиненнои таблице, если канесно связи установлены. 

Постой, я не шибко понял, почему у двух разных клиентов ID-шники получаются одинаковые? Ты как их генерируешь?

Потому что это две разные программы.


yesno, тут на форуме звучало мнение, что можно сделать ключи GUID'ами. Тогда коллизий не будет. А вообще тебе транзакции надо использовать. От каждого клиента все обновление должно происходить в рамках своей транзакции (и master, и child таблиц).

yesno, во-первых, сохранять в БД нужно сначала parent-таблицу, потом её child-таблицы. Например, если есть таблица Order и Customer, и в таблице Order есть поле CustomerID, то таблица Customer является главной, т.к. от неё зависит таблица Order. Соответственно, сохраняем адаптером (Update) сначала таблицу Customer, потом - Order.

Во-вторых, при добавлении в таблицу датасета записи, её primary key формируется по правилам датасета, а не по правилам БД. Это означает, что в качестве последнего значения autoincrement-а используется внутренне значение датасета, а не реальной базы данных. Само по себе в некоторых ситуациях это может привести к коллизиям с БД, поэтому официально MSDN рекомендует выставлять у таблиц датасета отрицательный autoincrement, начиная с -1.

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

kobra, а как нвстроить DataSet, чтобы кактолько я добавляю новую запись, она сразу записывалась на сервер и возвращался ее id. Может примерчик есть какойнить.

yesno, автоматически никак. DataSet - это отсоединенный источник данных. Только вручную вызывать DataAdapter.Update(DataSet)

а как это в книге David Sceppa Microsoft ADO.NET описано. может у кого есть сцылочка на эту книгу.

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

почитаи книжку что я рекомендовал. она лущая из тех которые мне поподалис.

Все большое СПАСИБА за советы и рекомендации. Нашлась ссылка которая решает мою проблему:
http://www.gotdotnet.com/Community/UserSam...61-CD83A5D5AD7A
Там решается немного другой баг с id-шниками, но проблема породившая его такаже самая как и в моем случае. Еще не пробовал сделать так как там говориться, но судя по примеру, мне это должно помочь. Всем советую посмотреть, может че нового для себя узнаете.

Типа чего?

Видимо, речь идёт о том, что адаптер обновляет таблицы по отдельности, и связи (relations) между ними после обновления теряются.