экспорт/импорт: неуникальный RecId

[Антон Солдатов]

Возникла проблема, при импорте данных компании возникает ошибка:
Невозможно создать запись в 'TmpRecIdMap'. Запись уже существует.

В принципе, проблема понятна, и некоторые идейки по ее решению есть, но все же:

Кто-нибудь с подобным сталкивался? Как лечили?

[Антон Солдатов]

причина: 1) неидеальный механизм присвоения RecId; 2) одновременно с импортом большого кол-во данных, другие пользователи создавали записи в других таблицах(м/б тоже импортировали).
как лечил: делал отчет: recid, tablename с неуникальными по recid записями. думал. делал экспорт/импорт(с очисткой) отобранных таблиц. проверка/синхронизация. вроде пока не шатается. эмоции негативные.

[Vadik]

а "проверка кодов записей" из "SQL Администрирования" что говорит?

[Антон Солдатов]

говорит, что temporary tablespace у меня маленький - один update с вложенными select-ами не проходит вечером еще раз запущу..

[denny]

Сам только что столкнулся. Помогает снятие параметра "Резервирование кодов записи" в настройках импорта. При этом выделение recId для импортируемых записей проходит по более сложному и долгому пути, но с гарантированной уникальностью (см. SysDataImport.importBuffer() и зависимость от значения параметра IsFastImport)

[Dozer]

Прошу прощения за поднятие очень старой темы, но возникла подобная проблема в аксапте 2009.
Таже самая ошибка:
Cannot create a record in Map (TmpRecIdMap).
The record already exists.
Возникает постоянно при попытке дублирования компании и при попытке импорта.
В 2009ой уже нет такого параметра "Резервирование кодов записи" (покрайней мере я не нашел), но я пошерстил код, и обнаружил что система импорта всё так же содержит переменную isFastImport, только теперь она привязана к чекбоксу "Use Record ID Compression".
К сожалению не зависимо от того снят этот чек бокс или установлен ошибка продолжает появляться.

Может кто-нибудь знает как это побороть?

[Dozer]

Ну раз никто не знает, то может быть подскажете какая в аксапте 2009 политика для RecId? В аксапте 3 вроде как RecId должен был быть уникальным в пределах одной компании.
А вот инфу по 2009ке я что-то найти не могу. Есть подозрения что он должен быть уникальным только в пределах одной таблицы. Это так или нет?
Оказывается каким-то образом в нескольких таблицах появились записи с идентичными RecId. Вот думаю как лечить.

[petr]

Уникальный в пределах таблицы, так же как и в четверке.

[DSPIC]

А чем грозит неуникальность RecId в рамках компании?
Стоит задача импорта данных в DAX из внешней системы. Простым способом видится создание таблицы нужной структуры в аксапте, но данные в неё будут толкаться внешней системой, на уровне SQL.
RecId при этом генерить автоинкрементно -> появятся дубликаты в рамках компании. Чем это грозит?

[TasmanianDevil]

Цитата:

Сообщение от DSPIC

Чем это грозит?

Если будет скопирована системная идеология забора значений из таблицы генератора RecID (сессия отжирает некую порцию значений, расходует его, отжирает следующую) - особых проблем быть не должно возникнуть. Но упаси бог автоинкремент строить в рамках таблицы - сломается все к чертям.
Если есть бизнес коннектор - лучше через него для вставки из сторонней программы оформить вызов класса, обрабатывающего заполнение полей абстрактной таблицы, вставку в в нее, благо дело есть класс Common, можно к полям по кодам обращаться, а извне данные по кодировке таблиц/полей доступны в таблице SqlDictionary. В этом случае проблем вообще быть не должно.

[DSPIC]

Цитата:

Сообщение от TasmanianDevil

... но упаси бог автоинкремент строить в рамках таблицы - сломается все к чертям...

Вот интересует именно этот момент. Что конкретно сломается? Данные этой "грязной" таблицы актуальны только на момент импорта, их не планируется куда-то потом переносить, и как-то их использовать в системе. Эта таблица будет только на чтение, запись в неё со стороны DAX не будет осуществляться. Т.е. можно представить, что эта таблица будет использоваться как View.

[raz]

Если эта таблица не будет связана по RecId с другими таблицами и её RecId не будет превышать системный, то проблем не будет.

Можно загрузить данные в промежуточную таблицу (которая потом будет не нужна), а потом джобом из DAX загрузить из промежуточной в нужную, тогда будет соблюдена идеология и RecId будет сгенерен системой.

[DSPIC]

Цитата:

Сообщение от raz

Если эта таблица не будет связана по RecId с другими таблицами и её RecId не будет превышать системный, то проблем не будет.

1. Превышать системный - это который текущий системный, или максимально возможный? Чуть подробнее, если можно.
2. И что всё-таки случится, если будет превысит? Есть примеры?

Цитата:

Сообщение от raz

Можно загрузить данные в промежуточную таблицу (которая потом будет не нужна), а потом джобом из DAX загрузить из промежуточной в нужную, тогда будет соблюдена идеология и RecId будет сгенерен системой.

Так и планируется. Это будут сырые данные которые будут обрабатываться (читаться) аксаптой, и на основе их где-то что-то обновляться...

[raz]

Цитата:

Сообщение от DSPIC

1. Превышать системный - это который текущий системный, или максимально возможный? Чуть подробнее, если можно.
2. И что всё-таки случится, если будет превысит? Есть примеры?

1. текущий системный
2. при дальнейшей работе в аксапте с этой таблицей, существует вероятность (мизерная, но существует) вставки записи с существующим RecId
3. я описывал проблемы в общем, в вашем случае их может не быть, т.к. загрузка будет единичной. однако таким образом можно загружать данные справочников, которые будут использованы в дальнейшем.

[AndyD]

В таблице записи накапливаются?

Можно, как вариант, создать дыру в RecId на максимальное кол-во записей в этой таблице и использовать recId из этого диапазона

Да и можно просто воспроизвести для генерации recId логику из DAX - тогда вообще не будет проблем (даже теоретических)

[Gustav]

А в дальнейшем эти сырые данные должны оставаться в системе? Если нет и общее кол-во этих записей ограничено размерами текущей порции загрузки, то можно нагенерить нужное кол-во recid (100 тыс. штук, например) и всё время использовать его. Или создать список пропущенных дыр и использовать его. Можно после использования просто для всех записей очищать все поля, кроме RecId, а при следующей загрузке не добавлять новые, а обновлять имеющиеся (по аналогии, как мы вводим данные в чистый лист Excel, где строки уже пронумерованы).

Упс! AndyD опередил и был конструктивно менее многословен

[DSPIC]

По поводу дырки - идея понятна, спасибо. И идея генерации RecId по должному алгоритму тоже понятна.
Вопрос чуть другой (услышьте вопрос ):
что будет, если RecId сгенерированы автоинкрементно, т.е. будут дабликаты в рамках компании (но уникальны в рамках таблицы)? Чем это грозит. Если ничем, то зачем морочиться с корректным алгоритмом RecId.

[AndyD]

Вопрос был услышан

Если не доживете до сжатия recId - то ничем не грозит.
В вашем случае, даже дублирование recId в одной таблице никак не скажется на работе (без контроля уникальности на уровне БД, естественно).

Но.
Если придется делать сжатие, если, в дальнейшем, кто-то настроит связку по recId с этой таблицей, то проблемы появятся

[alex55]

Цитата:

Сообщение от DSPIC

... т.е. будут дабликаты в рамках компании (но уникальны в рамках таблицы)?...

Наверное торможу под вечер, но разве такое возможно? оО