Добрый день!!!
При синхронизации базы КПК (sdf) и ПК (mdf) вышли трудности, относительно связей.
На КПК создаём клиента (он создался под ид 5), далее создаём компанию (он создался под ид 5123) где указано что оно связано с клиентом под ид 5.
Далее пересылаем это всё на ПК (передача осуществляеться инсерты, которые в xml-ке), там исполняется запрос (инсерт) и клиент получается под ид уже НЕ 5, а 8791 вот...и когда мы исполняем (инсерт) для компании то оно говорит мол под ид 5 нечего нету, ну и естественно вываливается ошибка.
Может кто сталкивался с такой проблемо? или знаеть какие нибудь утилы для синхронихации.
Жду ответов... 

vutsh, есть 2 старндартных способа:
1. Обычная репликация SQL Server. http://msdn.microsoft.com/en-us/library/ms152568.aspx
2. Sync services for ADO.NET: http://msdn.microsoft.com/en-us/library/bb726002.aspx

3) SET INSERT_IDENTITY ON
4) заменить id на GUID-ы и не мучаться с автоинкрементом

Спорное решение. С некоторых пор я с опаской отношусь к использованию Guid'ов.

и чем же они так тебя напугали?

jonie, 
1. отлаживать неудобно
2. индексы по ним много кушают и тормозят
3. про NEWSEQUENTIALID() даже management studio не знает

Обычный подход - rowguid, и int identity not for replication в качестве PK. Делается автоматом самой студией при настройке репликации с SQL. Более того, в конце management studio код для старта репликации под compact framework выдает...надо только копипастнуть

Это сообщение отредактировал(а) PashaPash - 25.3.2009, 22:22

jonie, ууу. Это долгая история 
Работал я над одним замечательным web-проектом. На этапе проектирования по каким-то причинам (которые мне так и не удалось выяснить) было решено использовать Guid'ы. Как потом оказалось, смысла в этом не было: можно было легко обойтись автоинкрементным id. А между тем Guid'ы:
1. В четыре раза тяжелее int
2. Почем зря фрагментируют индексы. Guid'ы генерировались из .NET'а, поэтому использовать NewSequentiald не было возможности. Хотя можно было прикрутить какой-нибудь workaround вроде этого, но он тоже неидеален
3. Т. к. проект представлял собой Web-приложение, Guid'ы частенько использовались в качестве Get-параметров, поэтому строка запроса даже при одном параметре (не говоря уже о двух и более) выглядела очень некрасиво. Пользователи пугались.

В итоге я решил взять на себя ответственность перевести базу на int'ы. Параллельно решил исправить несколько архитектурных (своих   ) багов (хоят, скорее, первопричиной изменений стали именно эти баги, а переход на int'ы стал следствием). Даже несмотря на то, что DAL реализовывался при помощи Entity Framework, переписывать пришлось кучу рутинного кода: приведение типов, Asp.net баиндинг и т. д. Конечно, большинство ошибок исправлялось при помощи Find&Replace... но попариться мне пришлось крепко: все-таки исправить около 1200 ошибок компиляции (да-да, проект был уже далеко не начальном этапе развития) - это не шутки. Я сел вечером в пятницу, закончил вечером воскресенья (вносил изменения в выходные, пока остальные не работали над кодом). Давно я так не волновался: был страх запороть все. Конечно, я в любой момент мог откатиться обратно... но делать этого очень не хотелось.

Как же приятно было в итоге увидеть желаемый результат... 

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

Вот такая дурацкая история. Здесь, конечно, по большому счету виноваты не Guid'ы, а моя кривая библиотека hands.dll... но тем не менее после этого случая к Guid'ам я отношусь с опаской 

Вот хороший анализ Guid'ов в плане производительности: раз, два. Если Select выполняется терпимо, то Insert тормозит не по-детски.


В смысле?

насчет тормозов конкретно в этой задаче несогласен. SQL CE ограничен и очень даже сильно.
ну вот конкретно это лично меня не пугает. Сейчас база с которой я работаю более 1800 ГБ ...

ну это Ваша багофича, POSTтитесь да прибудет с вами джа )

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

в остальном, конечно, да.. но стоит ли данная задача так заморачиваться на скорость - решать автору.
репликация доступна начиная с версии стандарт, если не ошибаюсь.

Да скорее всего буду делать через гуиды...

Только не вручную  заюзай репликацию, она сделает через гуиды почти автоматом.

jonie, а на нас сейчас кастомер в суд хочет подать и деньги забрать. Типа, софт не соответствует общепринятым стандартам. 
Придирки:
1. Использование GUID в качестве PK
2. Использование newid() вместо NEWSEQUENTIALID()
3. База не в 4-й NF
4. Использование ORM вместо ручной работы с sql....


А ты попробуй в дизайнере таблиц вбить значение по умолчанию (NEWSEQUENTIALID()) для колонки uniqueidentifier - она ругнется на синтаксическую ошибку, потребует 2 раза подтвердить перед сохранением.

А что вас побудило использовать Guid'ы?


Весьма спорная претензия.


А в чем претензия? Это каким-то образом снизило производительность или ограничило функционал? И, кстати, какая ORM использовалась? 


Хех... Действительно  Попробовал в Management Studio от 2008-го Sql Server - та же фигня.

Не нас. Моего предшественника ;)

Для сайта с /как выяснилось при сдаче проекта/ с требованием держать 1M транзакций в месяц -> необходимостью кластеризации -> упорядоченность ключа по времени - вполне нормальное требование.

Претензия примерно такая - сам заказчик писали проект на ASP.NET, и там орм тормозил. Поэтому все ормы тормозят. Потому что они выбирают данные из отдеельных таблиц, а не из специально обученных вьюшек...бла-бла-бла..."общепринятые индустриальные стандарты требуют ручной работы с sql, все остальное is evil". И вот докажи что не олень...

Юзали NetTiers (кстати, !!!НИКОГДА!!! не используйте NetTiers). 

Ааа. Вон оно что.


А что это за стандарты такие? Где почитать?  ORM - уже мэйнстрим, и это факт.


А тесты, доказывающие обратное, не пробовали проводить?

Мейнстрим по какому показателю? По количесву проектов - мейнстрим - это руби и php, без всяких орм. А аргументы в пользу ручной работы с sql всегда найти можно...например приложение будет расти, и придется делать какие-то "ручные оптимизации". А орм не дает полного контроля. А заказчику он воможно понадобится, поэтому "перепишите все заново, без ORM, и бесплатно".


Так заказчик тоже тесты проводить умеет... И к тому же он old school PHP-ник