OLAPAmount

[denny]

AX 3.0 SP3
Вопрос по таблице OLAPAmount. Два куба, перестраиваемые ежедневно, содержат вычисляемые данные по весьма большому периоду (около года). Ежедневно обновляемая таблица генерирует по 800 тысяч recid ежедневно. Естественно, такой прирост совершенно не устраивает, ибо несложно подсчитать, в течение какого весьма ограниченного времени будет пройден предел в заветные 4 миллиарда.

Варианты, которые пришли в голову и которые хотелось бы обсудить. Наверняка у сообщества есть опыт по решению таких вопросов.
Вариант первый - на регулярной основе восстанавливать бэкап основной базы на отдельной инсталляции, откуда и обрабатывать кубы. Плюсы - проблема с генерацией recid решается принципиально. Минусы - неудобство переноса и ручного запуска обработки кубов, потому что пакетную обработку при таком подходе не настроишь.

Вариант второй - у таблицы OLAPAmount выставить признак saveDataPerCOmpany = No, соответственно номера для recid будут браться из компании dat, которая на данный момент для работы не используется. Плюсы - отсутствие минусов первого варианта Минусы - неполное решение проблемы - для некоторого, пусть и весьма небольшого количества таблиц savedatapercompany также выставлен в No, соответственно при переходе через четырехмиллиардный предел возможны конфликты. (хотя они гораздо менее вероятны, чем при пересечении с recid в основной компании).

Возможно, слегка путанно объяснил. Готов переобъяснить, если требуется

Спасибо.

[kashperuk]

Еще варианты могу предложить - запускать периодически SysRecIdRepair - "сжатие идентификаторов записей" или как там оно называлось. Плюсы - если 800 тыс. записей с пред. дня не нужны и удаляются, то они будут использоваться повторно для других задач после "сжатия". Минусы - работоспособность класса страдает из-за несовершенности кода с использованием RecId/RefRecID

Перейти на 4.0/5.0 (2009). Там проблема отпадет сама собой.

[denny]

Спасибо. Тоже вариант, но из-за режима работы 24x7 вряд ли применим. Все топики про дефрагментацию recid уже просмотрел.

[glibs]

Еще можно строить кубики средствами MS SQL, а не встроенными средствами Аксапты.

Возможностей больше. Хотя недостатки тоже имеются.

[twilight]

А зачем вам таблица OLAP Amount? От нее смысл только в пересчете валют, как мне кажется.
И если пересчет валют не нужен, то можно сделать все средствами SQL Server.
И даже если он нужен, в 2005 сделали вроде функционал для пересчета валют (сам я его не пробовал, у меня кубы без пересчета)

[glibs]

Цитата:

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

...
И если пересчет валют не нужен, то можно сделать все средствами SQL Server.
...

И даже если нужен и очень захотеть, то тоже можно сделать.

Я писал на T-SQL функцию для конвертации. Правда, она не учитывала факта существования триангуляции. Но при желании можно написать и более универсальную.

Еще будет возня с перечислениями (Enum).

[denny]

Спасибо. Пожалуй, средствами SQL и реализуем. Самый очевидный вариант, действительно.

[AlexeyS]

Цитата:

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

Спасибо. Пожалуй, средствами SQL и реализуем. Самый очевидный вариант, действительно.

к тому-же будет быстрее считаться