Как правильно поставить Dynamics AX для нескольких стран

[Ivanhoe]

Возник такой вопрос. Как правильно поставить Dynamics AX с учетом работы нескольких стран в одной БД?

Какой collation должен быть на SQL Server / БД?
Какие настройки страны (отображение форматов, времени, кодовая страница) должны быть на AOS сервере?

[mazzy]

а какая версия?

в 2012 появилась новая опция - partition.
конфигурационные ключи работают в пределах одной partition.

до 2012 разные страны только из одной поставки. так, например, россию и болгарию можно было использовать, а россию и бразилию - нет.

collation - я бы посоветовал ставить тот, в котром работает штаб-квартира. все равно у кого-то будут сложности. так пусть это будут не начальники

[Ivanhoe]

Про partition и конфигурационные ключи пока вопрос не стоит. Там есть нюансы, есть обсуждения на этом форуме.

Пока вопрос именно про настройку серверов и SQL.

Речь скорее про AX 2012, но и 2009 имеем в виду.

[fed]

Я бы посоветовал ставить тот collation, в котором больше всего accented character.
Вообще говоря, учитывая что строки храняться в unicode (NVARCHAR), выбор collation становиться не таким критическим. В большинстве случаев, все более или менее удобоваримые символы есть во всех collation, даже если сам язык их и не использует. Могут быть заморочки с глубоко национальными языковыми фичами типа немецкого двойного SS или турецко-румынской буквы İ/ı (есть маленькие буквы ı и i, и большие I и İ. Правило toupper('i')=="I", вообще говоря не соблюдается). В общем - в идеале надо смотреть на то какие у вас страны и какие языки...
Кроме того - в каких-то случаях, клиент SQL Server CLIENT может посмотреть на кодовую страницу компьютера на котором он исполняется, и как-то замэппить свою кодовую страницу на кодовую страницу сервера. Но - опять таки надо пробовать. Если с какой-то страной у вас совсем плохо получилось - попробуйте ее на отдельный AOS вынести и там кодовую страницу установить на кодовую страницу страны... При этом надо понимать, что в каких-то случаях в результате подобной операции системе может поплохеть

[Ivanhoe]

Вот в том то и дело. Одно дело протестировать какую-то функцию в системе. Другое дело - забацать тестовую систему на кучке серверов / AOS и провести тестирование по кучке стран.
Понятно, что в таких случаях в проекте должно быть выделено достаточно ресурсов на подобные тестирования, но лучше заранее продумать как можно больше вариантов и опций

По языкам рассматриваем худший вариант с РФ, Германией, Финляндией, Казахстаном. Т.е. кучка местных особенностей в collation.

P.S. так еще на "подумать". До сих пор кучка систем сторонних работают не в Unicode. Потенциально - это еще одна проблема при попытке интегрироваться с такими системами и особенностями настройки серверов СУБД и AOS.

[fed]

С другой стороны - индекс у тебя все равно построен по одной collation sequence и как ты там с клиентскими настройками не играйся, сортировки по другим collation вынуждены будут пересортирововать каждый раз таблицы. (Что крайне неприятно для производительности).
Так что, возможно и вправду стоит тупо поставить везде одну и ту же collation, просто с выбрав ту, которая с культурной точки зрения устроит наибольшее число пользователей.

[Logger]

Цитата:

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

Так что, возможно и вправду стоит тупо поставить везде одну и ту же collation, просто с выбрав ту, которая с культурной точки зрения устроит наибольшее число пользователей.

В SQL server вроде можно свой Collation для столбца таблички задавать. Наверно можно и для индекса. Почему бы не попробовать ?

[vmoskalenko]

Цитата:

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

С другой стороны - индекс у тебя все равно построен по одной collation sequence и как ты там с клиентскими настройками не играйся, сортировки по другим collation вынуждены будут пересортирововать каждый раз таблицы. (Что крайне неприятно для производительности).
Так что, возможно и вправду стоит тупо поставить везде одну и ту же collation, просто с выбрав ту, которая с культурной точки зрения устроит наибольшее число пользователей.

Так и делали для одного проекта (AX2009), где участвовали языки: Русский, Украинский и Итальянский. Поставили на SQL вот такой collation SQL_Latin1_General_CP1_CI_AS и запустились. На производительности пока не сказывается.

Самым "сложным" было, при работе напрямую с SQL-таблицами, добавлять букву N перед текстовой строкой. Что-то типа:

PHP код:

select * from inventtable where itemid=N'Болт' 


P.S. Юникод - это сила!

[ISaminov]

до 2012 разные страны только из одной поставки. так, например, россию и болгарию можно было использовать, а россию и бразилию - нет.