Проблема производительности при использовании виртуальных компаний.

[db]

Цитата:

Сообщение от 7Up

NODATAAREAID - имеется в виду SaveDataPerCompany = No?

Эта картинка как отключить в конф утилите. Такой же параметр есть и в настройка аоса. Делать надо на базе, в которой только одна компания - DAT. Естественно надо отсинхронизировать базу после запуска с таким ключом. Поле DataAreaId испарится из всех таблиц и индексов

По поводу опасений использования данной возможности - по крайней мере три очень нехилые розничные сети работают несколько лет с таким ключиком. Версии 3.0 от без СП до KR1. Проблем никаких.

А насчет производительности - протестируйте сами и решите сами. Не хочется ввязываться в очредную войнушку

[7Up]

2 vadic. Все-таки насчет настройки выделения recId для отдельных таблиц не могли бы вы уточнить как именно это можно настроить или где посмотреть.
Если вдруг волшебный ключ noDataAreaId дает существенное улучшение производительности ваш вариант становится оптимальным.

[Vadik]

Цитата:

Сообщение от 7Up

2 vadic. Все-таки насчет настройки выделения recId для отдельных таблиц не могли бы вы уточнить как именно это можно настроить или где посмотреть

Почитать можно в документе, полное название - "Microsoft® Business Solutions-
Axapta® V3.0 Databases Advanced".
Выглядит настройка незатейливо - взводится флаг (бит) 64 в поле VALUE записи INDEX в SQLSYSTEMVARIABLES

[ziva]

Цитата:

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

Почитать можно в документе, полное название - "Microsoft® Business Solutions-
Axapta® V3.0 Databases Advanced".
Выглядит настройка незатейливо - взводится флаг (бит) 64 в поле VALUE записи INDEX в SQLSYSTEMVARIABLES

Не все так просто под луной. Когда устанавливаете данный флаг и перезаходите в Axapta, RecId действительно выбираются для определенной таблицы, примерно вот так:
SELECT NEXTVAL FROM SYSTEMSEQUENCES WHERE DATAAREAID = 'dat' AND
ID = -1 AND TABLID = 33
а вот когда происходит следующий оператор обновления последовательности, то этого не происходит:
UPDATE SYSTEMSEQUENCES SET NEXTVAL = 12322 WHERE DATAAREAID = 'dat' AND ID = ... AND TABLID = 0

Вот и получается что эта "фича" не работает. После продолжительных переговоров с поддержкой MBS выяснилось что это "by design" и соответственно корректную работу данной функциональности никто не обещал.

По результатам телефонного митинга с John McBride (менеджер команды разработки) и Mathieu Kemenovic (глобальная служба поддержки) мне подтвердили что они ничего менять в 3.0 не будут (и даже не будут делать private hot-fix) и предоставлили набор SQL-скриптов, которые ищут большие "дырки" последовательности идентификаторов записей и используют их. Данные скрипты неавтоматические и необходимо выполнять ряд шаманских танцев с бубнами...

Кроме того, если у Вас действительно имеются проблемы с нехваткой RecId и это является ну очень-очень критичным для бизнеса, единственным приемлимым вариантом решения проблемы является переход на 4ку. Поскольку для Вас это вынужденное обновление, то представляется вероятным получение от Microsoft каких-либо benefits. Каких? Тут все зависит от Вас. Сами понимаете, что Microsoft-у не нужен негативный отклик на рынке по причине отказа крупного клиента от Axapta.

[ziva]

Прошу прощения за оффтопик:

Цитата:

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

... если у Вас действительно имеются проблемы с нехваткой RecId ...

Возвращаясь к теме...

Цитата:

Сообщение от 7Up

Предлагается: разнести таблички с большим количеством записей по разным виртуальным компаниям

Это самое простое и быстрое решение, которое позволит оттянуть "конец" Аксапты на вашем предприятии.
На производительность никак не повлияет (ядро вместо одного кода компании будет просто подставлять другой).

[Garic]

Цитата:

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

Почитать можно в документе, полное название - "Microsoft® Business Solutions-Axapta® V3.0 Databases Advanced".

А где его можно взять?
Что-то не нашёл на parnerSource.