|
![]() |
#1 |
Участник
|
Новые записи в таблице без генерации recId
Создаю свой отчет взамен стандартного (есть сильное желание ускорить выполнение). Заполняю временную таблицу, а затем вывожу ее в отчет с попутной информацией. Чтобы в итоге получить нужную сортировку и дополнительную информацию соединяю ее с InventTable по itemId в отчете. В итоге сортировка по InventTable идет страшно медленно и сводит на ноль эффект оптимизации.
Сделал вместо временной таблицы постоянную с полем номерсеанса. При запуске отчета по номеру сеанса сначала чищу потом заполняю. В итоге желаемый эффект значительного ускорения достигнут. Но возник у меня вопрос с бесполезной тратой номеров recId для генерации постоянной таблицы. По грубой оценке на данный момент отчет в месяц будет генерить около 100-150тыс левых номеров. Есть нормальный выход из ситуации или можно забить и оставить как есть? |
|
![]() |
#2 |
Administrator
|
Сделайте таблицу в специальной компании или вообще поставьте SaveDataPerCompany = No. Тогда временами можно будет более или менее безболезненно сбрасывать счетчик для RecId.
__________________
Not registered yet? Register here! Have comments, questions, suggestions or anything else regarding our web site? Don't hesitate, send them to me |
|
![]() |
#3 |
Роман Долгополов (RDOL)
|
SystemSequence.suspendRecIdGeneration(tablenum(...))
|
|
![]() |
#4 |
Участник
|
Цитата:
Сообщение от db
SystemSequence.suspendRecIdGeneration(tablenum(...))
systemSequence.lockRecidGeneration и systemSequence.suspendRecIds Я взял первую попробовать и она вроде как работает. Какую использовать правильнее даже не знаю. Справки нет. О них видимо знает только шаман db.)) |
|
![]() |
#5 |
Участник
|
suspendRecIds() используется в методе SysDataImport.importData().
При вызове lockRecidGeneration() у меня Axapta уходит сама в себя
__________________
Axapta v.3.0 sp5 kr2 |
|
![]() |
#6 |
Участник
|
Цитата:
Сообщение от Perc
Но возник у меня вопрос с бесполезной тратой номеров recId для генерации постоянной таблицы. .....
Есть нормальный выход из ситуации или можно забить и оставить как есть? |
|
![]() |
#7 |
Роман Долгополов (RDOL)
|
ну извиняйте. Когда писал, аксапты под рукой не было
надо systemSequence.suspendRecIds(_tableId); при этом вместо реальных RecId в таблицу будут набиваться по очереди 2 "левых" значения а systemSequence.lockRecidGeneration(_tableId); просто блокирует раздачу RecId для заданной таблицы, при попытке выделить RecId для такой таблицы Аксапта повиснет Счастливая новость для всех - в 4.0 новый базовый тип int64 и RecId основан на нем |
|
![]() |
#8 |
Участник
|
Цитата:
Сообщение от db
systemSequence.suspendRecIds(_tableId);
при этом вместо реальных RecId в таблицу будут набиваться по очереди 2 "левых" значения
__________________
Axapta v.3.0 sp5 kr2 |
|
![]() |
#9 |
Участник
|
RecId - это тип Integer. Его предельно допустимое значение = 2,147,483,647. Выполняем простой расчет:
2,147,483,647 / 150,000 / 12 = 1,193 лет Т.е. при такой интенсивности расхода номеров переполнение может произойти примерно через тысячу лет. Не морочь себе голову всякой ерундой! Резерва хватит даже при увеличении интенсивности печати отчета в 100 раз. А если учесть, что допустимо использовать еще и отрицательные значения... |
|
![]() |
#10 |
Шаман форума
|
Цитата:
Сообщение от Владимир Максимов
RecId - это тип Integer. Его предельно допустимое значение = 2,147,483,647. Выполняем простой расчет:
2,147,483,647 / 150,000 / 12 = 1,193 лет
__________________
All information in this post is strictly confidential. If you have read it in error, please forget it immediately. |
|
![]() |
#11 |
Участник
|
Цитата:
Сообщение от komar
А что есть цифра 150000? Думается мне, цифра эта будет у каждого своя. Например, ...
При этом уточняется, что это значение формируется для некой таблицы, использующейся исключительно для хранения промежуточных результатов расчета для отчета. При такой постановке задачи - можно не волноваться. Существующая функциональность не потребует переделки. Ее резерва на это хватит с большим запасом. Кроме того, насколько я понимаю, записи периодически удаляются. Т.е. количество записей в самой таблице в каждый момент времени будет относительно невелико. Ну, предположим, те же 150 тысяч. Это значит, вопрос стоит не в том, чтобы сохранить все те миллиарды записей, которые когда-либо будут созданы при формировании всех отчетов в обозримом будущем, а только вот для этого небольшого количества записей. По сути, вопрос сводится к тому, что произойдет при переполнении значения RecId, при условии, что физическое количество записей в таблице относительно невелико. Порядка 150 тысяч. Если я правильно понимаю логику присвоения очередного значения RecId, то ничего страшного. Дошли до максимума в 2 миллиарда, далее RecId начал присваивать отрицательные значения. Когда дойдет до 0 что произойдет дальше? Опять начнет присваивать положительные значение? Ну, и какие проблемы? |
|
![]() |
#12 |
злыдень
|
Цитата:
Сообщение от Владимир Максимов
Если я правильно понимаю логику присвоения очередного значения RecId, то ничего страшного.
Дошли до максимума в 2 миллиарда, далее RecId начал присваивать отрицательные значения. Когда дойдет до 0 что произойдет дальше? Опять начнет присваивать положительные значение? Ну, и какие проблемы? Не знаю у кого через какие тысячелетия, а у нас месяца через 3 Аксапта скажет Йо...с и успешно остановит свою работу.. |
|
![]() |
#13 |
Шаман форума
|
Проблемы в возможном их пересечении, насколько я понимаю. То есть не появится ли в будущем, после выбора отрицательных id положительный с таким же значением, как уже бывший когда-то в системе. Собственно, это уже обсуждалось, здесь, например Как выполнять дефрагментирование RecID
__________________
All information in this post is strictly confidential. If you have read it in error, please forget it immediately. |
|
![]() |
#14 |
злыдень
|
Цитата:
Сообщение от komar
Проблемы в возможном их пересечении, насколько я понимаю. То есть не появится ли в будущем, после выбора отрицательных id положительный с таким же значением, как уже бывший когда-то в системе. Собственно, это уже обсуждалось, здесь, например Как выполнять дефрагментирование RecID
|
|
![]() |
#15 |
злыдень
|
2 db:
а хакнуть эту дрянь можно? |
|
![]() |
#16 |
Участник
|
|
|
![]() |
#17 |
злыдень
|
читал. ерунда всё это.. ну оттянем конец на месяц? я понимаю на инт64 перейти .. а так..
|
|
![]() |
#18 |
Участник
|
вы можете подсчитать количество ваших записей
Например, Сервис \ Средства разработки \ количество записей в таблицах или DBCC SHOWCONTIG WITH TABLERESULTS в MS SQL? Сколько вас реально записей? |
|
![]() |
#19 |
злыдень
|
Цитата:
Сообщение от mazzy
или DBCC SHOWCONTIG WITH TABLERESULTS в MS SQL?
Сколько вас реально записей? Спасибо, будем ковыряться.. |
|
![]() |
#20 |
Участник
|
Извиняюсь. Был не прав.
Забыл, что RecId - это глобальная штука на все таблицы в пределах одного значения DataAreaId. Тогда все мои возражения - не о том. Они имеют смысл, если бы RecId рассчитывался в пределах одной таблицы. В качестве предложения по ускорению работы отчета - проиндексируй временную таблицу по ItemId. И именно по временной таблице и делай сортировку. Ну, и я бы не делал объединение временной таблицы и InventTable. Использовал бы Display-методы для вытягивания нужной информации из InventTable. |
|
Теги |
recid |
|
|