Блок А.Н.1.А старые значения ID восстановить нельзя?
Если будете при загрузке менять ID, это слишком большая проблема, оно вам точно надо?

Да, мне тоже хотелось бы восстановить старые значения ID.
Но этого сделать не получается. При явном указании значения поля ID в insert-запросе вылетает ошибка про невозможность пользовательского задания автогенерируемого значения.

Дело в том, что в исходной (экспортируемой в скрипт) таблице код ID в общем случае не обязательно идет последовательно, после длительной работы пользователей с таблицей очень вероятно, что значения поля ID будут разрежены. Сохранив эту таблицу в скрипт (даже со знаениями полей ID) возникает проблема последующей загрузки скрипта в таблицу (пускай даже чистую). На это накладывается требование сохранения связей между таблицами.

Блок А.Н.2. Попробовать использовать естественные ключи вместо суррогатных.

К сожалению я не знаю как настроить relationship между классами на основе значений естественных ключей. К тому же не хочется добалять дополнительные PK когда и так есть ID.

VadimFВ Cache' есть синхронизация объектов.
Для реализации синхронизации в Cache' есть поддержка GUID.
Глобальный уникальный идентификатор как раз позволяет решить проблему, которую Вы описываете.

Почитайте документацию на эту тему.
Советую использовать GUID!

Спасибо за совет, посмотрел. Это конечно все очень хорошо,мощно и интересно. Но применять средство поддержки репликации баз для решения простых задач импорта/экспорта данных по-моему это как из пушки по воробъям. Хочется более простого решения.

PtnЕсли решить проблему дублирования ID ... то указать ID в INSERT можно, достаточно завести поле ID и назначить его IDKEY.

Проблемы дублирования ID у меня нет, я готов предварнительно очищать глобалы с данными. Интересно только, сохраняется ли при таком подходе внутреннее поле %ID ? И как-то переделывать все классы базы данных не хотелось бы. Но большое спасибо за очень ценный совет.


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

Правда если у вас есть уже работающая система - этот способ не подойдет.

Спасибо. Ваш пост совместно с постом уважаемого Ptn проянили механизм настриваемого для ID поля. Это наверно лучшее решения, единственная проблема в том, механизм импорта/экспорта данных с сохранением связности объектов хотелось бы иметь более-менее универсальный, по возможности не сильно привязанный к описаниям классов. Предполагалось описания классов получать динамически, выявлять какое поле является ID, и сохранять это в строки вида
Вообщем идея в том, что бы экспортировать данные взаимосвязанных классов (без предварительного изменения их структуры введением собственных IDKEY полей) в текстовый sql-подобный скрипт. А потом в новую (или предварительно очищенную) базу залить данные из этого скрипта, так чтобы связи между объектами сохранились.

Итого: GUID - тяжеловесно,
собственный естественный ключ с IDKEY - хорошо, но требует предварительной модификации классов. Хотелось бы универсального решения без изменения структуры базы.