RecID при экспорте-импорте не восстанавливаются?

[mazzy]

В теме Чем грозит использование RecId в качестве ПК?

была фраза о том, что "RecID при экспорте-импорте не восстанавливаются"
Объясните, пожалуйста, что вы имели в виду?

Насколько я знаю, экспорт/имопрт обрабатывает RecID при импорте. Например таблицы LedgerTableInterval, MarkupTrans импортируются корректно.

Да, у него бывают глюки когда таблица после экспорта была включена/исключена в коллекцию.
Да, у него бывают глюки, если в таблице есть больше одного поля с RecID. Например CustSettlement импортируется отвратительно.

Что нибудь еще?

[Андре]

Только что экспортнул CustTabel и импортировал ее обратно. Делал это через группы определений.

Экспортировал с одним RecId, когда импортировал - оказались совсем другие.

[mazzy]

Да, записи то поменялись.

Ты экспортируй те таблицы, которые содержат RecID в качестве внешнего ключа (FK).
Например, LedgerTable и LedgerTableInterval.

После импорта RecID в обеих таблицах изменятся!
Но ссылки будут указывать на те же записи, что и до импорта.
RecID изменяются СОГЛАСОВАННО.

Не всегда правда

[Dron AKA andy]

Насколько я знаю, ссылки наиболее корректно (на 99%) переносятся, если использовать специальный тип RefRecId для FK. Еще важно, чтобы экспорт связанных таблиц проводился в один прием, вместе. И при этом, естественно, primary table должна импортироваться раньше, чем ее child tables!

[mazzy]

Насчет RefRecID - не уверен. См. CustSettlement.
С порядком импорта сам импорт разбирается.
С полнотой данных согласен.

Есть ли еще какие пункты, кроме табличных коллекций и множественных RefRecID, при которых импорт может ошибиться?

[Dron AKA andy]

Не нашел в табл. CustSettlement полей с RefRecId Между прочим, про этот тип мне как-то давно сказал один бывалый АХАРТА-программер, и с тех пор я в подобных случаях всегда использую его.
А по поводу порядка импорта - ни#$# он не разбрается Наступил уже на эти грабли при переходе с 2.1 на 2.5. Вроде бы с RefRecId все переносится ОК, из всей массы таблиц примерно десяток (из разработанных нами) содержит ссылки по RecId. А одна таблица (в которой, по закону подлости, приличный объем данных скопился ) ни в какую ссылки не поднимает, хоть ты тресни! В итоге оказалось, что каким-то там макаром эта дочерняя таблица заимела TableId меньше (т.е. раньше), чем родительская! И экспорт, выгружающий данные как раз в порядке id таблиц, переносил дочернюю таблицу раньше родительской, снося по дороге все ссылки.

[mazzy]

О!
Так он их по TableID упорядочивает и импортирует именно в этом порядке?
Уверен?

[mazzy]

Ага. А OffsetRecID в таблице CustSettlement действительно имеет тип RecID.
Спасибо. Надо подумать.
И... разобрать таки подробно класс импорта/экспорта.

[Dron AKA andy]

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

[mazzy]

Это да.
Но вроде импорт сначала считывает что содержится в dat-файле и пытается что-то сделать с этими определениями.

Насколько я понял, здесь принимаются решения о согласованном изменении RecID. Здесь же, вроде, принимается решение о порядке импорта.

В свое время, я посмотрел на этот чудовищный код и не стал с ним разбираться. Похоже зря. Может знаешь, где эта байда описана?

[fed]

Мы когда-то всерьез разбирались с процедурами импорта-экспорта. Выяснилось следующее:
При экспорте в файл экспорта записывается максимальный и минимальные recid в текущей компании. (Далее maxOldRecid,minOldRecId).
При импорте - в пространстве recid резервируется MaxOldRecId-minOldRecId штук идентификаторов записей (начиная с newMinRecId). Далее, для любого поля типа recId, или любого расширенного типа, унаследованного от типа recid, в поле записывается значение newMinRecId+oldRecId-minOldRecid. Таким образом ссылки - восстанавливаются. Нужно только чтобы все таблицы, связанные по recid импортировались/экспортировались одновременно. Для ссылок по tableid используется аналогичное правило. Axapta при импорте ведет таблицу соответствия tableid в старом приложении и tableid в новом приложении, и выполняет трансляцию для всех полей, имеющих тип tableid или любой унаследованный от него.

К сожалению - трансляция recid точно не работает при одновременном экспорте таблиц из реальных компаний и виртуальных. Насколько я понимаю - в экспортном файле записывается minOldRecId и maxOldRecId только для одной компании. (Возможно - текущей - тогда с виртуальными компаниями вообще дело плохо) Соответственно - корректно преобразовать одни старые recid в новые система вообще не может. Связано это с тем, что счетчики recid хранятся в разрезе компаний (в таблице systemsequences).

Как итог:
При работе с виртуальными компаниями - импорт-экспорт теряет ссылки по recid
Импортировать связаные по recid таблицы нужно одновременно.

[mazzy]

Спасибо

[Pavel]

Цитата:

Изначально опубликовано fed
в пространстве recid резервируется MaxOldRecId-minOldRecId штук идентификаторов записей (начиная с newMinRecId).

А такая вещь как шаг изменения RecId для последовательно создаваемых записей в диапазоне есть? Специфический для каждой конкретной таблицы?

[SIRS]

Таблица SystemSequences - системная, из АОТ-а недоступная.
Там хранится информация по полу доступных RecId.

[Pavel]

Цитата:

Изначально опубликовано SIRS
Таблица SystemSequences - системная, из АОТ-а недоступная.
Там хранится информация по полу доступных RecId.

Уже нашел ответ на свой вопрос. Через SQL можно открыть базу и любую таблицу и спомощью view просмотреть записи.
Принцип формирования RecId не изменился, значение шага - 48 (как и в XAL ).