Поле с кодом "0"...

[V777]

что означает ошибка
Поле с кодом "0" в таблице "Такой то" не обнаружено.

что за код??? куда копать??? причем выскакивает методе класса где эта таблица вообще не упоминается...

[Yprit]

там, наверное, map упоминается... Который и надо посмотреть...

[miklenew]

Цитата:

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

куда копать???

В класс info метод add

[V777]

Цитата:

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

там, наверное, map упоминается... Который и надо посмотреть...

мап упоминается я его просмотрел...да в нем есть это поле но оно нифига не заполняется...но мап по другаму обзывается и к этой таблице тоже отношения не имеет как я понял...

[Yprit]

Мэп - это всего лишь попытка распространить принципы ООП на табличные переменные. А операции производятся с реальными таблицами, согласно структуре мэппинга. Чтобы не гадать - покажите кусок кода, ну или просто настройте меппинг "Поле мэпа -> поле таблицы, на которое ругается"

[V777]

мда действительно...спасибо...

[kaw]

Столкнулся с такой же ошибкой, map вроде бы не участвует...
\Classes\PurchTotals\calc
currency = purchTable.CurrencyCode;

purchTable.CurrencyCode = "RUR" - инициал.через vendTable.
в ошибке: "Поле с кодом 0 в таблице PurchParmTable не обнаружено."

[ZVV]

может банальная [глобальная] перекомпиляция поможет?

[Alexx7]

Такая же ошибка при разноске/проверке журнала.
проверка проходит после прогонки Job с кодом

    RPayJournalTrans    rPayJournalTrans;
    int                 i = 1;
    ;

    ttsbegin;

    while select forupdate rPayJournalTrans
        where rPayJournalTrans.JournalId == 'Номер журнала который не разносится'
    {
        rPayJournalTrans.LineNum = i;
        rPayJournalTrans.update();
        i ++;
    }

    ttscommit;

Но постоянно прогонять джоб тоже не вариант. А проблема так и не уходит. Что можно сделать?

[nano3]

Цитата:

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

может банальная [глобальная] перекомпиляция поможет?

можно сначала попробовать compile forward
Объявляем переменную - в дебагере нету

[kaw]

Компиляция не помогает (ни глобальная, ни инкрементная).

Забыл указать Kernel 4.0.2501.116
Application 4.0.2501.121
Retail version: R7.04.0800.0

[mazzy]

http://axapta.mazzy.ru/lib/exploreerror/

[Alexx7]

Цитата:

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

http://axapta.mazzy.ru/lib/exploreerror/

Ну здесь только как найти ошибку, используя отладчик. Совершенно не ясно почему возникает эта ошибка? т.е. в какой момент пользователь делает что то не так... если в результате журнал не проверяется/разностися а дает такую ошибку.
см. мой пост выше.

[mazzy]

Цитата:

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

Совершенно не ясно почему возникает эта ошибка?

Там же все написано - используйте стек отладки. поднимайтесь по стеку, чтобы выяснить первопричину.

если вас смущает то, что у пользователя: включите ему средства разработки и поставьте ему точку останова. попросите его позвать вас как только он увидит что-то непонятное и красное

[gl00mie]

Цитата:

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

purchTable.CurrencyCode = "RUR" - инициал.через vendTable. в ошибке: "Поле с кодом 0 в таблице PurchParmTable не обнаружено."

Если по факту у вас - таблица PurchTable, а Аксапта пишет про PurchParmTable, то, видимо, ее где-то переклинило на счет id-шиков таблиц. С учетом того, на каком слое расположены таблицы, остается только шаманить с компиляцией, удалением индекса приложения, удалением кэшей на клиенте...
PS. Буквально вчера словил аналогичную ошибку на собственном Map'е для двух таблиц. Одно и то же отмапленное поле с одной таблицей работало нормально, а с другой - приводило к вылету ошибки про нулевой идентификатор. В моем случае вылечилось лишь после удаления Map'а из AOT, заливки его по-новой без сохранения идентификаторов и нескольких перекомпиляций всего кода, ссылавшегося на Map. Но, очевидно, когда объекты расположены на sys/dis/gls-слоях, это - не выход.

[kaw]

Цитата:

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

http://axapta.mazzy.ru/lib/exploreerror/

в данном случае в начале вылетает ошибка Debugger-а
а потом уже система дублирует ее в инфолог
запускает info.add()

[Peter Savintsev]

Цитата:

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

Такая же ошибка при разноске/проверке журнала.
проверка проходит после прогонки Job с кодом

    RPayJournalTrans    rPayJournalTrans;
    int                 i = 1;
    ;

    ttsbegin;

    while select forupdate rPayJournalTrans
        where rPayJournalTrans.JournalId == 'Номер журнала который не разносится'
    {
        rPayJournalTrans.LineNum = i;
        rPayJournalTrans.update();
        i ++;
    }

    ttscommit;

Но постоянно прогонять джоб тоже не вариант. А проблема так и не уходит. Что можно сделать?

Это старый известный баг (странно, что до сих пор не поправили). Правда, он несколько из другой серии, нежели вышеприведенные сообщения. Тут проблема в том, что из-за некорректного индекса на RPayJournalTrans неверно работает автонумерация строк (присвоение значений полю LineNum) при создании строк журнала через форму RPayJournalTrans. Автонумерация строк журнала опирается на то, что LineNum должен быть уникальным в рамках каждого журнала, см. таблицы строк стандартных журналов InventJournalTrans, ProjJournalTrans, ProdJournalBOM, ProdJournalRoute. В этом плане в LedgerJournalTrans есть небольшое отличие, но оно связано с ваучером и особенностями разноски строк журнала ГК.

Наши же локализаторы, как всегда пошли своим путем, создав на RPayJournalTrans индекс JournalLineIdx и засунув в него помимо JournalId и LineNum еще кучу полей. В результате, автонумерация, которая обеспечивается заполнением свойства CounterField на дата-сорсе, работает некорректно. Решение достаточно простое:
1. Создать уникальнай индекс на таблице RPayJournalTrans из двух полей: JournalId и LineNum (именно в таком порядке). Тут надо быть осторожным, если у вас уже есть кривые журналы с неправильными номерами строк, необходимо выполнить джоб для их перенумерации, наподобие того, что привел выше Alexx7.
2. На форме RPayJournalTrans у одноименного дата-сорса в свойстве Index указать созданный в п.1 индекс.

После этого разноска журнала зарплаты не будет вызывать описанной ошибки.