DataAreId и Partition в индексах

[Hyper]

В индексах, соданных в AOT, в добавок к полям, добавленным пользователем, в начале индекса всегда автоматически добавляются поля Partition и DataAreaId (если есть).

К примеру, в таблице SalesLine индекс TransIdx в AX содержит только поле InventTrans. При этом в SQL Server этот индекс содержит три поля: Partition, DataAreaId, InventTransId - именно в этом порядке.

Много лет назад, уже и не помню в какой версии Аксапты, на вроде бы одном из семинаров рассказывали, что с помощью какой-то достаточно простой конфигурации это поведение по умолчанию можно изменить так, чтобы Partition и DataAreaId добавлялись в конец индекса, а не в начало. То есть, после синхронизации базы данных индекс в SQL Server выглядел бы так: InventTransId, DataAreaId, Partition.

С тех пор много воды утекло, и так как сейчас гугление ничего по этому поводу не обнаружило, я уж и не уверен, не было ли это ложными воспоминаниями.

Подскажите, пожалуйста, кто в теме.

[rDenis2]

Если не ошибаюсь, надо в аксапте в АОТ, создать индекс и включить в него системные поля, dataareaid и т.д.

[Hyper]

Quote:

Originally Posted by rDenis2

надо в аксапте в АОТ, создать индекс и включить в него системные поля

Нет-нет, речь идёт именно о глобальной конфигурации в AX, которая бы затронула все индексы без необходимости их коррекции в AOT.

[sukhanchik]

Видимо вспоминается вот это сообщение
aEremenko: Порядок полей в индексе для DAX 3.0
Но в 2012 табличку SQLSYSTEMVARIABLES уже убили и на ее смену пришла табличка SYSGLOBALCONFIGURATION, в которой нет такого параметра.
Про нее только информация про литералы (т.е. как подставить в план запроса конкретные значения Partition и Dataareaid) встречается, а не про индексы

[Hyper]

Quote:

Originally Posted by sukhanchik

Видимо вспоминается вот это сообщение
aEremenko: Порядок полей в индексе для DAX 3.0

Да, то что надо, спасибо!

Quote:

Originally Posted by sukhanchik

Но в 2012 табличку SQLSYSTEMVARIABLES уже убили

Да нет, вот же она у меня перед глазами.

PARM	VALUE	IPARM	IVALUE
INDEX	297	13	NULL

[sukhanchik]

Quote:

Originally Posted by Hyper

Да нет, вот же она у меня перед глазами.

Хм... и правда... Даже в D365FO она есть

[Logger]

Если компания одна, то можно так

https://yandex.ru/search/touch/?text...2328018&lr=213

[Alexius]

Я бы не рекомендовал "ковровые бомбардировки", лучше разбираться точечно.

[Hyper]

Quote:

Originally Posted by Logger

Если компания одна, то можно так

Это не для последних версий, да и для одной компании мне не актуально.

SQLSYSTEMVARIABLES - это именно то, что я искал. Я вчера протестировал в AX 2012 - DataAreaId и Partition действительно переносятся в конец индекса, хотя я ожидал, что Partition будет последнем полем в индексе, но почему-то в конце находится DataAreaId, а Partition идет перед ним.

[Logger]

На всякий случай добавлю, что 4-й битик надо взводить. Т.е. вместо 297 поставить 313

[Logger]

Из документации к 3-ке :

Quote:

Value ‘0’ for indexes not supported, or
one or more of the other options
added together:
0 : Not supporting indexes.
1 : Default flag for enabling index
support.
2 : Index generation reversed (i.e.
most important index generated last).
4 : Allow DESC on index components
in CREATE INDEX statement.
8 : Add table qualifiers to index
Axapta System Variables Page 13-7
names.
16: Put the DATAAREAID (the
“company field) last in indexes, and do
not put the field in the ORDER BY
clause at all.
32: This session is using “RECIDs per
company”, which consequently will
add the DATAAREAID to the built-in
RecId-index.
64: This session is using “RECIDs per
company+table”

[Hyper]

Quote:

Originally Posted by Logger

На всякий случай добавлю, что 4-й битик надо взводить. Т.е. вместо 297 поставить 313

Да, я так и тестировал.