Ax2009, сбросить кеш recid SystemSequences

[Pandasama]

Ситуация следующая:
Через SQL-запрос (запускаемый из X++) вставляю большое количество записей в таблицу.
Таблицу SystemSequences в том же запросе обновляю.
Однако при дальнейшей попытке вставить в эту же таблицу запись уже в X++ получаю конфликт recid.
При проверке обнаруживаю, что SystemSequence.ReserveValues() для этой таблицы возвращает значение меньшее, чем значение в таблице SystemSequences.

Насколько я знаю, в каждой сессии RecId для таблицы выделяются пачками, которая кешируется в клиенте. И подозреваю, что следующий RecId после моих манипуляций с данными, выбирается все ещё из старого кеша, а не берется новая пачка значений из таблицы SystemSequences.

Вопрос: как в данной ситуации сбросить кэш выбранных RecId для того чтобы спокойно продолжить вставку в таблицу без конфликтов?

[S.Kuskov]

Вставка строк в таблицы Аксапты сторонними средствами

[Pandasama]

Все бы хорошо, но в моем Ax2009 в systemSequence в Ax2009 нет метода flushCache()

[Dron AKA andy]

В идеале - перезапустить бы АОС после обновления SystemSequences.

[Pandasama]

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

[Pandasama]

Путем эксперимента выяснилось, что, похоже, нужный эффект дает следующая комбинация:
1) обновляем значение в таблице SystemSequences
2) делаем suspendRecIds для нужной таблицы
3) делаем removeRecIdSuspension для неё
По крайней мере на моем конкретном примере это проблему решило, если это не случайное совпадение

[dech]

А что именно вы делаете в запросе?
ИМХО, чистый SQL лучше использовать для экзотической SELECT-выборки. остальные операции следует выполнять штатными средствами. Если вы хотите вставить пачку записей, чем плох RecordInsertList?

[Pandasama]

Для вставки на основе существующих записей необходим перебор записей через while select (или query), наполнение RecordInsertList и его вставка.
В SQL это делает одним каким-нибудь INSERT INTO xxx SELECT * FROM a JOIN b JOIN c
Что выполняется на порядок быстрее, вплоть до вставки в несколько миллионов записей за 5-10 минут (зависит от сложности джойнов). На X++ это занимает часы

[DSPIC]

Quote:

Originally Posted by Pandasama

Для вставки на основе существующих записей необходим перебор записей через while select (или query), наполнение RecordInsertList и его вставка.
В SQL это делает одним каким-нибудь INSERT INTO xxx SELECT * FROM a JOIN b JOIN c
Что выполняется на порядок быстрее, вплоть до вставки в несколько миллионов записей за 5-10 минут (зависит от сложности джойнов). На X++ это занимает часы

- если 2012 и выше, то в идеале лучше так сделать так insert_recordset [AX 2012]. И не забыть про fall back to record-by-record operations. См. также Query::insert_recordset Method [AX 2012]

- если версия по-старше, то пара suspendRecIds + removeRecIdSuspension обязательна.

- Обновлять же самому SystemSequence допускается только в случаях Application Maintance

[dech]

Quote:

Originally Posted by Pandasama

Для вставки на основе существующих записей необходим перебор записей через while select (или query), наполнение RecordInsertList и его вставка.
В SQL это делает одним каким-нибудь INSERT INTO xxx SELECT * FROM a JOIN b JOIN c
Что выполняется на порядок быстрее, вплоть до вставки в несколько миллионов записей за 5-10 минут (зависит от сложности джойнов). На X++ это занимает часы

Значит что-то мешает insert_recordset выполниться за одну инструкцию.
Вы уверены, что skipDataMethods(), skipDatabaseLog() не помогают?

[Pandasama]

Нет возможности средствами X++ сделать insert_recordset - слишком сложные условия.
В SQL это выполняется (иногда через дополнительные промежуточные временные таблицы).
А в X++ это вырождается в цикл получения записей + вставка записей через InsertRecordList
В итоге SQL на порядки быстрее

Впрочем, речь не об о том, нужно ли писать в базу через SQL, а о том как сбросить кэш recid в 2009й версии.

[dech]

Quote:

Originally Posted by Pandasama

Нет возможности средствами X++ сделать insert_recordset - слишком сложные условия.
В SQL это выполняется (иногда через дополнительные промежуточные временные таблицы).
А в X++ это вырождается в цикл получения записей + вставка записей через InsertRecordList
В итоге SQL на порядки быстрее

Впрочем, речь не об о том, нужно ли писать в базу через SQL, а о том как сбросить кэш recid в 2009й версии.

А можно взглянуть на запрос? Уж очень заинтересовало.)))
По сабжу посмотрите здесь пример:
https://msdn.microsoft.com/en-us/library/aa638594.aspx

[Владимир Максимов]

Да при чем здесь запрос! Основной тормоз Вы поимеете на закачке этой кучи записей на AOS и последующий возврат обратно на SQL. А время выполнения собственно запроса уже становится не критичным

Если речь идет о вставке миллионов записей, которые формируются непосредственно в базе SQL, то прокачка их через AOS для вставки средствами Axapta - крайне медленная операция.

[iCloud]

AX 2009, 2012:

    systemSequence seq = new SystemSequence();
  
    if (seq) 
    { 
        // Выделяем 20 записей SalesTable
        seq.reserveValues(20, tablenum(SalesTable)); 
 
        // Приостановить автоматическое распределение RECID
        seq.suspendRecIds(tablenum(SalesTable)); 
 
        // Вручную генерим RecId в выбранном диапазоне, если необходимо 
 
        // Снять остановку распределения 
        seq.removeRecIdSuspension(); 
      }

AX 4.0:

    systemSequence::flushCache();

[Pandasama]

Quote:

Originally Posted by Pandasama

Путем эксперимента выяснилось, что, похоже, нужный эффект дает следующая комбинация:
1) обновляем значение в таблице SystemSequences
2) делаем suspendRecIds для нужной таблицы
3) делаем removeRecIdSuspension для неё
По крайней мере на моем конкретном примере это проблему решило, если это не случайное совпадение

Как выяснилось - не помогло

Только диагноз теперь хуже:
при попытке выделить новые RecId для таблицы, для которой SystemSequence изменен в запросе - через N значений выделенных (руками выделенных или вставкой - не важно) - получаю мертвую блокировку на таблице SystemSequence. Ну и значения выделяются меньше, чем те что в SystemSequence прописаны - из каких-то старых кэшей, видимо

[Владимир Максимов]

Не обновляйте вручную таблицу SystemSequences. Только через класс SystemSequences в среде Axapta

Я делаю так:

1. Средствами SQL определяю количество записей, которые будут вставлены
2. В среде Axapta через класс SystemSequences резервирую нужное количество значений
3. Средствами SQL выполняю создание записей и формирование RecId

Вот фрагмент для резервирования RecId в Ax4.0

// Резервирование значений RecId для создания записей средствами SQL
// Возвращает первое зарезервированное значение RecId
protected int64 runReserveRecId(TableId _tableId, int64 _reservedRecords)
{
    systemSequence  systemSequence;
    Int64           beginRecId;
    ;

    systemSequence = new systemSequence();

    // Приостановить автоматическое распределение RecId для указанной таблицы
    systemSequence.suspendRecIds(_tableId);

    // Выделяем нужное количество записей
    beginRecId = systemSequence.reserveValues(_reservedRecords,_tableId);

    // Снять остановку распределения
    systemSequence.removeRecIdSuspension(_tableId);

    return beginRecId;
}

Далее в SQL передаем как параметр полученное значение beginRecId и прибавляем к нему порядковый номер вставляемой записи (начиная нумерацию с нуля).

Например, если подготовили к вставке 10 записей, а beginRecId = 12345, то соответственно будут значения RecId от 12345 до 12354

PS: Так и не понял, откуда все берут статический метод

systemSequence::flushCache();

Нет такого в Ax4.0 Совсем нет

[Pandasama]

Да, я вчера пришел к подобной же мысли, только реализовать решил по-другому:
(чтобы не разбивать запрос на две части - подсчет количество и саму вставку)
делаю заморозку выделения RecID
выполняю запрос
резервирую разницу между следующим RecId и фактическим RecId после вставки в таблицу
снимаю заморозку

но реализация что-то не работает:

--start
----макс. recid в таблице 5642940489, systemsequences.nextval 5642940490
--suspend
--before query
----макс. recid в таблице 5642940540, systemsequences.nextval 5642940740
----systemsequence.reserve(1) = 5642940543
--execute insert query
--after query
----макс. recid в таблице 5642945298, systemsequences.nextval 5642940740
----systemsequence.reserve(1) = 5642940544
----systemsequence.reserve(4754 {5642945245 - 5642940491 - разница между след. рекид и фактическим рекид}) = 5642940740
--removesuspend

--а теперь проверим, какой RecId будет следующий
--suspend
----systemsequence.reserve(1) = 5642940545 //будто бы не было reserve(4754)
--removesuspend

По идее, я зарезервировал 4754 RecId начиная с 5642940740 - то есть следующий номер должен быть 5642940740 + 4754
Или у меня неверные представления о работе резерва, и система не только резервирует, но ещё и по факту отслеживает вставку записей с этими RecId ?

Впрочем, с выделением ДО запроса ситуация такая же:
выделил скопом 10000 (больше реально вставляемых 4754), получил recid 5642990876, значение в systemSequence.nextVal = 5643000876
вставил запросом в таблицу
выделил ещё 1 для проверки - получил 5642980716, значение меньше стартового RecId от первого выделения

[Pandasama]

ну и вообще, вот такой джоб

static void Job342(Args _args)
{
    SystemSequence      sysSeq = new SystemSequence();
    int64               recId;
    ;
    sysSeq.suspendRecIds(tablenum(VendTable));
    
    recId = sysSeq.reserveValues(1, tablenum(VendTable));
    info(strfmt("after reserve 1 = %1", recId)); //5637264076
    recId = sysSeq.reserveValues(10000, tablenum(VendTable));
    info(strfmt("after reserve 10000 = %1", recId)); //5637264327
    recId = sysSeq.reserveValues(1, tablenum(VendTable));
    info(strfmt("after reserve 1 = %1", recId)); //5637264077
    
    sysSeq.removeRecIdSuspension(tablenum(VendTable));
}

выдает результаты:
5637264076
5637264327
5637264077

то есть третий резерв возвращает значение меньше чем второй

[Владимир Максимов]

Quote:

Originally Posted by Pandasama

выдает результаты:
5637264076
5637264327
5637264077

то есть третий резерв возвращает значение меньше чем второй

У меня возвращает корректно. Применительно к Вашему примеру последнее число было бы

5637274077

Обратите вниманием на окончание: 74077, а не 64077, как у Вас. Возможно, Вы просто невнимательно посмотрели на число в этом разряде?

Quote:

Originally Posted by Pandasama

(чтобы не разбивать запрос на две части - подсчет количество и саму вставку)

Разбивать по любому придется.

Дело в том, что Axapta резервирует часть значение RecId. Т.е. определение значения по полю таблицы systemsequences.nextval ни о чем не говорит. Далеко не факт, что именно это значение и будет использовано в среде Axapta для генерации следующего значения. Как следствие, Вы рискуете присвоить не корректные значения RecId. Те, с которыми позже произойдет пересечение при обычной работе Axapta

Другими словами недопустимо на основании systemsequences.nextval сфоромировать RecId, а потом попросить Axapta зарезервировать NN значений. Не получится, поскольку Axapta может начать резервирование вовсе не с того значения, которое указано в systemsequences.nextval


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

// Этап 1 выборка во временную таблицу
if object_id('tempDB..#NewData') is not null drop table #NewData;
select
       (...)
      , identity(int,1,1) as RowNum
into #NewData
from (...)

// Подсчет записей. Это значение считываем в Axapta
select count(*) from #NewData

// Этап 2
// Резервирование RecId в Axapta 
// И передача начального номера RecId в SQL

// Этап 3 - Вставка в итоговую таблицу
//               beginRecId - переданное начальное значение

insert into MyTable 
      (...
      ,RecId
      )
select 
      ...
     , #NewData.RowNum - 1 + beginRecId
from #NewData

Я использую динамическое формирование запроса в среде Axapta, поэтому временные таблицы. Если использовать хранимые процедуры SQL, то придется делать постоянные таблицы