Запись уже существует!?

[propeller]

Из одной компании выгрузил файл (dat) с клиентами. В другой компании пытаюсь загрузить, выдает ошибку:

Невозможно создать запись в Клиенты (CustTable). Счет клиента: АБРИКОС, ООО "АБРИКОС".
Запись уже существует.

НО такого клиента нет в этой компании со счетом клиента "АБРИКОС". Проверял всеми способами и в аксапте запросы писал, и фильтром, и на SQL посмотрел.

Такое ощущение что проблема в RecId, буд-то он его из файла грузит.
Запускал реиндексацию - не помогла

Как исправить эту ошибку?

[Geo]

Очевидный вопрос, но тем не менее: все варианты написания "АБРИКОС" проверили?

[Raven Melancholic]

Что если в параметрах загрузки установить флаг "Обновлять существующие записи" (или как он там называется в вашей версии - кстати, неплохо бы привести версию).
Ну и обычные шаманские пляски:

• Может быть справочник клиентов включен в виртуальную компанию?
• Перед загрузкой рестартовали AOS?
• Чистили кэш?

[propeller]

АБРИКОС искал во всех вариантах. "абрикос" это условный пример. на самом деле там несколько записей, и на всех ошибка.
Таблица не в виртуальной компании, аос перестартовывал - не помогло.
Кэш, если имеется ввиду пользовательский - чистил.
версия - AX 2009 sp1.
причем база SQL обновленная с AX 4. в 4-ке такой прием работал, нормально загружалось.
Проверял по RecID в таблице (на SQL) с таким записей нет , кроме оригинальной.

Так же код на трансляцию справочников выдает туже ошибку

changecompany("k3")
{    
   _newrecord = new DictTable(_record.tableId).makeRecord()
....
                if (!_newrecord)
                {
                     buf2buf(_record,_newrecord);
                     _newrecord.doinsert();

                }
                else
                {
                     buf2buf(_record,_newrecord);
                     _newrecord.doupdate();
                }
}

Причем doinsert() или doupdate() - ошибка все таже

[Ivanhoe]

Проверьте счетчик RecID. Вполне возможно, что из-за прямых вмешательств в БД он не актуален.

Ага, БД из 4.0 - все больше шансов что это именно счетчик RecId. Он хранится в таблице, на память не скажу, но название достаточно интуитивное. Таблицу надо смотреть в компании DAT.

[Ivanhoe]

Таблица - SystemSequences, посмотреть можно через AOT - System Documentation.

[propeller]

Цитата:

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

Ага, БД из 4.0 - все больше шансов что это именно счетчик RecId. Он хранится в таблице, на память не скажу, но название достаточно интуитивное. Таблицу надо смотреть в компании DAT.

Уже пробовал - В таблице SYSTEMSEQUENCES на скле нашел запись для этой таблицы (tableId = 77) для компании дат. и в поле NEXTVAL подставил единичку в начало. Перестартанул AOS все равно не помогло.


Вот запись об этой таблице
id nextVal minVal maxVal cycle name tabId dataAreaId recVersion RecId
-1 5637168173 1 9223372036854775807 false SEQNO 77 dat 801014967 -1

Причем, если я добавляю новую запись в справочник то она нормально транслируется в другую компанию. Если же делаю update() существующих записей то такая ошибка.
Опять же, если я в консолидирующей компании, руками создаю клиента - все нормально никаких ошибок.

[Bober]

propeller, поставьте для начала брейкпойнт в инфологе и посмотрите в этой точке, какая конкретно запись находится: с каким рекидом, в какой компании, и т.д. По-моему, это первое, что надо было сделать, чтобы начать разбирательство.

[propeller]

Цитата:

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

propeller, поставьте для начала брейкпойнт в инфологе и посмотрите в этой точке, какая конкретно запись находится: с каким рекидом, в какой компании, и т.д. По-моему, это первое, что надо было сделать, чтобы начать разбирательство.

Это я и делал в первую очередь.
в info\add попадает из
[s]\Classes\xRecord\doinsert Запись эта находится в консолидирующей компании.
С каким RecId неизвестно. в info такой информации не нашел.
а до вызова
_newrecord.doinsert(); RecId у записи еще равен 0

Еcли _newrecord.doupdate() ([s]\Classes\xRecord\doupdate) ошибка:
Невозможно отредактировать запись в Клиенты (CustTable). Счет клиента: АНАНАС, ООО "АНАНАС".
Запись уже существует. (Причем RecId у записи какой и должен быть)

Не понимаю причем тут update() и запись уже существует... Существует и надо ее обновить..

[Raven Melancholic]

Цитата:

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

Запись эта находится в консолидирующей компании.

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

[propeller]

Цитата:

Сообщение от Raven Melancholic

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

Что вы имеете ввиду?
Это собственная доработка, трансляция клиента в другую компанию.
в 4-ке все это работало на отлично.

[Raven Melancholic]

Я имею ввиду, что если в компании в параметрах главной книги стоит флаг "Консолидирующая компания", то создать там запись клиента не особенно получится.
Попробуйте создать запись не программно, в вручную.

[propeller]

Цитата:

Сообщение от Raven Melancholic

Я имею ввиду, что если в компании в параметрах главной книги стоит флаг "Консолидирующая компания", то создать там запись клиента не особенно получится.
Попробуйте создать запись не программно, в вручную.

Нет, флаг не стоит.
Руками запись создается нормально.

[Raven Melancholic]

Цитата:

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

Нет, флаг не стоит

Цитата:

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

Запись эта находится в консолидирующей компании.

В Аксе есть четкое определение консолидирующей компании, если флаг не стоит, то это с точки зрения Аксы не является консолидирующей компанией, поэтому расскажи ,что значит консолидирующая компания с вашей точки зрения - стандарт, судя по всему, к вам не относится.
Ну и "код в студию". Подробности опусти, начни с места changeCompany, заполение полей, за исключением ключевых опусти, приведи только ключевые поля и места, где заполняются ключевые поля. При этом покажи как обнуляются переменные при смене компании (то есть, есть ли конструкции типа custVend = null и т.п.)

[Raven Melancholic]

Кстати. Для Ax30 была рекомендация при смене компании обнулять переменную, то есть, делать что-то подобное:

changeCompany('XXX') {
{
    custTable = null;
}

В DAX4 часто этого недостаточно. Если только что искали запись по коду и после этого переключились в другую компанию и ищем по тому же коду, то обнуление переменной может не сработать!!! Как-то странно работает кэш. Не знаю как в 2009, но в DAX4 кроме обнуления переменной нужно еще запретить кеширование, то есть делать что-то подобное:

changeCompany('XXX') {
{
    custTable = null;
    custTable.disabeCash(true);
}

Причем, обнаружил эту особенность на таблице InventTrans, которая вообще не кэшируется! Получилось так, что в результате работы механизма Интеркомпани - получлось так, что лот в одной компании (по которому только что был произведен поиск, совпал с лотом в другой компании, для которой ищем лот). Если в одной компании нашли лот, то после переключения на другую компанию этот лот не ищется, а возвращается запись из первой компании!!!
После этого взял в привычку после переключения компаний запрещать кеширование. В нашем коде нет проблем, а в стандартном делам это по мере обнаружения проблем. Так что, залезь в код импорта и вставиь в нужные места для переменной записи перед её заполнением .disableCash(true).

[Raven Melancholic]

Для примера, работал примерно такой код:

InventTrans inventTrans;
InvenTrans inventTransNew;
InventTransId transId = 'Скл000001';

// Работеем в компании AAA

select firstOnly inventTrans where inventTrans.InventTransId == transId;
if (inventTrans )
{
    changeCompany('BBB')
    {
        inventTransNew = null; 
        select firstOnly inventTransNew where inventTransNew.InventTransId == transId;
    }
}

Лот с номером ''Скл000001' есть как в компании AAA, так и в компании BBB. В вышеприведеном коде в inventTransNew попадала та же запись, что и в inventTrans!!!
Если же запретить кэш:

select firstOnly inventTrans where inventTrans.InventTransId == transId;
if (inventTrans )
{
    changeCompany('BBB')
    {
        inventTransNew = null; 
        inventTransNew .disableCach(true);
        select firstOnly inventTransNew where inventTransNew rans.InventTransId == transId;
    }
}

то в компании BBB находилась запись именно этой компании, а не AAA.
Так что начиная с DAX4.0 затим нужно следить не только в своем коде, но и в стандартнм.

[Logger]

Цитата:

Сообщение от Raven Melancholic

Причем, обнаружил эту особенность на таблице InventTrans, которая вообще не кэшируется! Получилось так, что в результате работы механизма Интеркомпани - получлось так, что лот в одной компании (по которому только что был произведен поиск, совпал с лотом в другой компании, для которой ищем лот). Если в одной компании нашли лот, то после переключения на другую компанию этот лот не ищется, а возвращается запись из первой компании!!!
После этого взял в привычку после переключения компаний запрещать кеширование. В нашем коде нет проблем, а в стандартном делам это по мере обнаружения проблем. Так что, залезь в код импорта и вставиь в нужные места для переменной записи перед её заполнением .disableCash(true).

Судя по описанным симптомам, могло повлиять вот это :
Глюки RecordViewCache

Правда у меня все это воспроизводилось в Ax 3.0
Для 4-ки не проверял.