Новые записи в таблице без генерации recId

[Perc]

Создаю свой отчет взамен стандартного (есть сильное желание ускорить выполнение). Заполняю временную таблицу, а затем вывожу ее в отчет с попутной информацией. Чтобы в итоге получить нужную сортировку и дополнительную информацию соединяю ее с InventTable по itemId в отчете. В итоге сортировка по InventTable идет страшно медленно и сводит на ноль эффект оптимизации.
Сделал вместо временной таблицы постоянную с полем номерсеанса. При запуске отчета по номеру сеанса сначала чищу потом заполняю. В итоге желаемый эффект значительного ускорения достигнут. Но возник у меня вопрос с бесполезной тратой номеров recId для генерации постоянной таблицы. По грубой оценке на данный момент отчет в месяц будет генерить около 100-150тыс левых номеров.
Есть нормальный выход из ситуации или можно забить и оставить как есть?

[Maxim Gorbunov]

Сделайте таблицу в специальной компании или вообще поставьте SaveDataPerCompany = No. Тогда временами можно будет более или менее безболезненно сбрасывать счетчик для RecId.

[db]

SystemSequence.suspendRecIdGeneration(tablenum(...))

[Perc]

Цитата:

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

SystemSequence.suspendRecIdGeneration(tablenum(...))

Такой функции нет, а есть
systemSequence.lockRecidGeneration и
systemSequence.suspendRecIds
Я взял первую попробовать и она вроде как работает.
Какую использовать правильнее даже не знаю. Справки нет. О них видимо знает только шаман db.))

[AndyD]

suspendRecIds() используется в методе SysDataImport.importData().

При вызове lockRecidGeneration() у меня Axapta уходит сама в себя

[savel]

Цитата:

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

Но возник у меня вопрос с бесполезной тратой номеров recId для генерации постоянной таблицы. .....
Есть нормальный выход из ситуации или можно забить и оставить как есть?

Побобную "отчётную" таблицу я помещаю в отдельную виртуальную компанию. (компания для отчётов). И RecId'ы отъедаются там.

[db]

ну извиняйте. Когда писал, аксапты под рукой не было

надо
systemSequence.suspendRecIds(_tableId);
при этом вместо реальных RecId в таблицу будут набиваться по очереди 2 "левых" значения

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

Счастливая новость для всех - в 4.0 новый базовый тип int64 и RecId основан на нем

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

RecId - это тип Integer. Его предельно допустимое значение = 2,147,483,647. Выполняем простой расчет:

2,147,483,647 / 150,000 / 12 = 1,193 лет

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

Не морочь себе голову всякой ерундой! Резерва хватит даже при увеличении интенсивности печати отчета в 100 раз. А если учесть, что допустимо использовать еще и отрицательные значения...

[AndyD]

Цитата:

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

systemSequence.suspendRecIds(_tableId);
при этом вместо реальных RecId в таблицу будут набиваться по очереди 2 "левых" значения

У меня, если не указывать ручками RecID, пытается вбить 0 и вылетает по констрайнту на RecID.

[komar]

Цитата:

Сообщение от Владимир Максимов

RecId - это тип Integer. Его предельно допустимое значение = 2,147,483,647. Выполняем простой расчет:

2,147,483,647 / 150,000 / 12 = 1,193 лет

А что есть цифра 150000? Думается мне, цифра эта будет у каждого своя. Например, если имеем 70000 объектов ОС, да три модели учета - вот уже и на одних основных вылезли далеко за 150000 в месяц. А ведь нужно журнальчик создать, журнальчик разнести, связанные таблицы заполнить, налоговый учет построить....и везде recid жрет, жрет....думаю, тут тысячей лет не пахнет. Тут десятком лет в лучшем случае пахнет. А кроме основных еще ууууух!!!!

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

Цитата:

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

А что есть цифра 150000? Думается мне, цифра эта будет у каждого своя. Например, ...

Я отвечаю на вполне конкретный вопрос, заданный в самом первом топике темы. Не "что будет если вдруг прилетят марсиане?", а "стоит ли озаботится возможным переполнением RecId при формировании порядка 150 тыс новых значений ежемесячно?".

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

При такой постановке задачи - можно не волноваться. Существующая функциональность не потребует переделки. Ее резерва на это хватит с большим запасом.

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

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

По сути, вопрос сводится к тому, что произойдет при переполнении значения RecId, при условии, что физическое количество записей в таблице относительно невелико. Порядка 150 тысяч.

Если я правильно понимаю логику присвоения очередного значения RecId, то ничего страшного.

Дошли до максимума в 2 миллиарда, далее RecId начал присваивать отрицательные значения. Когда дойдет до 0 что произойдет дальше? Опять начнет присваивать положительные значение? Ну, и какие проблемы?

[komar]

Проблемы в возможном их пересечении, насколько я понимаю. То есть не появится ли в будущем, после выбора отрицательных id положительный с таким же значением, как уже бывший когда-то в системе. Собственно, это уже обсуждалось, здесь, например Как выполнять дефрагментирование RecID

[Recoilme]

Цитата:

Сообщение от Владимир Максимов

Если я правильно понимаю логику присвоения очередного значения RecId, то ничего страшного.

Дошли до максимума в 2 миллиарда, далее RecId начал присваивать отрицательные значения. Когда дойдет до 0 что произойдет дальше? Опять начнет присваивать положительные значение? Ну, и какие проблемы?

Ага, и будет бегать по кругу аки лошадка цирковая...
Не знаю у кого через какие тысячелетия, а у нас месяца через 3 Аксапта скажет Йо...с и успешно остановит свою работу..

[Recoilme]

Цитата:

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

Проблемы в возможном их пересечении, насколько я понимаю. То есть не появится ли в будущем, после выбора отрицательных id положительный с таким же значением, как уже бывший когда-то в системе. Собственно, это уже обсуждалось, здесь, например Как выполнять дефрагментирование RecID

Мы уже в "минусе" пока проблем не наблюдаем .. тьфу-тьфу-тьфу

[Recoilme]

2 db:
а хакнуть эту дрянь можно?

[mazzy]

Как выполнять дефрагментирование RecID
экспорт/импорт: неуникальный RecId

[Recoilme]

читал. ерунда всё это.. ну оттянем конец на месяц? я понимаю на инт64 перейти .. а так..

[mazzy]

вы можете подсчитать количество ваших записей

Например, Сервис \ Средства разработки \ количество записей в таблицах
или DBCC SHOWCONTIG WITH TABLERESULTS в MS SQL?

Сколько вас реально записей?

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

Извиняюсь. Был не прав.

Забыл, что RecId - это глобальная штука на все таблицы в пределах одного значения DataAreaId. Тогда все мои возражения - не о том. Они имеют смысл, если бы RecId рассчитывался в пределах одной таблицы.

В качестве предложения по ускорению работы отчета - проиндексируй временную таблицу по ItemId. И именно по временной таблице и делай сортировку. Ну, и я бы не делал объединение временной таблицы и InventTable. Использовал бы Display-методы для вытягивания нужной информации из InventTable.

[Recoilme]

Цитата:

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

или DBCC SHOWCONTIG WITH TABLERESULTS в MS SQL?

Сколько вас реально записей?

фигасе... 400 млн всего... куды она подевала Ыщё 2 миллиарда интересно??? Или она их с "зазорчиком" резервирует?
Спасибо, будем ковыряться..