Будьте осторожны с RecordInsertList

[miklenew]

1) Создаю таблицу новую (Table1)
2) Создаю текстовое поле (field1) (string 10 по умолчанию)
3) В insert таблицы пишу.

public void insert()
{
    super();
    info("ttttttttttttttttttttttttttttttttttttttttttt");
}

4) Запускаю джобик

static void Job14(Args _args)
{
    RecordInsertList    recordInsertList    = new RecordInsertList(tablenum(Table1));
    Table1 table1;
    int i;
;
    for(i=0;i<4000;i++)
    {
        table1.Field1 = int2str(i);
        info(table1.Field1);
        recordInsertList.add(table1);
    }
    recordInsertList.insertDatabase();
}

И вижу что в add на цифрах 1067, 2135, 3203 идёт сброс данных в таблицу не в insertDatabase(), а в add.
Провожу экспиримент сначала.
Только коментирую insertDatabase(). Те которые уже сбросились так и остались в таблице до 3203, а которые не успели в таблицу не попали.
Расширяю поле в таблице до 20 знаков.
Снова провожу экспиримент, цифры сброса уже другие 743, 1487, 2231, 2975, 3719.
Если взять например класс xRefCreate метод updateDBReferences, то

                                if (!xRefReferences::find(phantomCallReference.xRefNameRecId, phantomCallReference.xRefPathRecId))
                                {
                                    recordInsertList.add(phantomCallReference);
                                }

Перед тем как закинуть в буфер новую строку идёт проверка есть ли уже такая, и только тогда сбрасывается.
А ведь может выйти такая ситуация.
Сбрасываем десять записей, на восьмой буфер переполнился и произошёл сброс.
В той строке которую я написал находиться 9 строка, в базе её ещё нет. А в буфере она есть так как не было сброса. Добавляем в буфер 9 строку повторно и на insert database они обе идут в таблицу.
Просто у меня стоит локально Ax 3.0 sp1 и мало того что перекрёстные ссылки считаются 8 часов, так они ещё и задваиваются кое-где. На Ax 3.0 sp4 (не локально трёх звенка) задвоений нет, и считается быстро. Хотя классы xRefCreate и xRefUpdate одинаковые.
И думаю возможно причина здесь. Пока не знаю, до конца ещё не докопал.
Но впечатление, что человек писаший обновление перекрёстных ссылок не знал о подобном эффекте (преждевременного сброса буфера).
Но ведь такие места наверное есть и вдругих местах.
Вообщем будь те осторожны с recordInsertList, на верное его из-за этого и убрали из Ax 2009.
aEremenko: DAX 2009, работа с несколькими компаниями

[sukhanchik]

Тут нет ничего необычного. Просто метод insertDatabase не делает вставку в БД (как кажется из названия), а сбрасывает буфер (flush). На это надо рассчитывать. С перекрестными ссылками - да, подстава небольшая есть... но опять-таки зная как оно работает..... можно вполне сделать все правильно.
Зато этот класс (RecordInsertList) был очень удобным для массовой вставки записей, особенно если надо было сделать какой-то джобик по историческим данным. Ускорение (у меня) было раз в 6 по сравнению с обычным insert. Да и тут (Есть ли выигрыш от RecordInsertList) тоже говорилось о приросте производительности. Кстати в той же ветке есть и цитата из документации, в которой сказано, что записи вставляются не одноразово, а как ядро аксапты сочтет более нужным...

[miklenew]

Цитата:

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

но опять-таки зная как оно работает..... можно вполне сделать все правильно.

Поэтому и написал чтоб понятнее было.

[kashperuk]

Цитата:

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

Вообщем будь те осторожны с recordInsertList, на верное его из-за этого и убрали из Ax 2009.
aEremenko: DAX 2009, работа с несколькими компаниями

Его никто не убирал.
Просто crossCompany функциональность не поддерживается этим классом - об этом и пишет Алексей.

[miklenew]

Цитата:

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

Его никто не убирал.
Просто crossCompany функциональность не поддерживается этим классом - об этом и пишет Алексей.

Сложно сказать что он имел ввиду под фразой

Цитата:

Правда не поддерживаются базовые структуры типа RecordInsertList и RecordSortedList.

Мне показалось что он писал здесь не про crossCompany.

[kashperuk]

Ну, во-первых, я перед тем, как писать, конечно же открыл АХ 2009 и проверил, что класс этот есть и работает.
А во-вторых, его не могли убрать хотя бы потому, что он используется на слишком большом кол-ве внедрений. А мы ж пытаемся не ломать код существующий

[miklenew]

Цитата:

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

Ну, во-первых, я перед тем, как писать, конечно же открыл АХ 2009 и проверил, что класс этот есть и работает.
А во-вторых, его не могли убрать хотя бы потому, что он используется на слишком большом кол-ве внедрений. А мы ж пытаемся не ломать код существующий

Значиться заблуждался.
Спасибо что поправили.