Временные SQL таблички в ax2009

[Raven Melancholic]

Цитата:

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

Возможно для исключения каких либо экстремальных случаев использования функциональности дельт стоит предусмотреть проверку на appl.ttsLevel() перед обращениям к таким таблицам.

Тут даже проще можно, есть метод для проверки того, нужно ли использовать дельты для номенклатуры:

InventUpdateOnhandGlobal::mustAddInventSumDeltaOnhand(itemId)

Спасибо за информацию, поэкспериментирую на кошках.

[db]

Цитата:

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

Хотя это некоторый офтопик в этой теме, но проблема блокировок и дидлоков по LedgerBalancesTransDelta лечится простым удалением индекса по RecId. Просто ставишь в свойствах таблицы createRecIdIdx==No и проблема решается.

Лечится но не излечивается. Проблема там основная с удалением записей из дельты, а не с селектами/вставками. Игры с индексами (которые мы тоже проходили) облегчают положение дел. Но на тысячах (слово было вставлено не для красного словца, это действительно так) параллельных постоянно работающих разносок дельты (как складская, так и финансовая) постоянными вставками/ударениями моментально превращаются по физической структуре в хлам (околонулевое к-во записей, пара гигабайт размер, фрагментация индексов 99,99%), с которой сервер адекватно работать отказывается. Пробовали с кластерными индексами и без кластерных и раком и боком и вверх ногами. Пробовали перестроения индексов по шедулеру. Но онлайн перестроение при такой нагрузке ничего не исправляет, офлайн исправляет, но при этом само всё лочит. Настоящие темповые таблицы проблемы не облегчают, а именно решают.

[db]

Никаких чудес. За всеми этими обертками tablename2id() и dictTable.makeRecord(). С учетом неявных предположений об одинаковых FieldId в таблицах с решеткой и без, отсутствие перекрестных ссылок на инициализацию вообще за грех можно не считать.

tablename2id('#mInventSumDeltaKeyTmp');