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

[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-ки не проверял.