Переход на четвёрку - Unicode

[Garic]

Благодаря этому чудесному новвоведению появилась возможность вести номенклатурный справочник на албанском.
Но есть и побочные эффекты - размер базы увеличивается.
В нашем случае - inventTrans увеличился с 13 гигабайт до 31. Это без индексов (а с ними так вообще).
Общий размер базы увеличился примерно в два раза.

Есть ли у кого-то идеи - как отключить сию безусловно полезную в наших реалиях функциональность?

Пока всё что нашёл - это ключ UNICODEENABLED в
SQLSYSTEMVARIABLES. Но это не помагает.

В принципе, если переконвертить средствами СКЛ поле из nvarchar в varchar - Аксапта это проглатывает. Даже при синхронизации ничего не пытается переделать. Но как-то стрёмно, например если сменить EDT - возвращает обратно в nvarchar.

[mazzy]

Цитата:

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

Благодаря этому чудесному новвоведению появилась возможность вести номенклатурный справочник на албанском.
Но есть и побочные эффекты - размер базы увеличивается.
В нашем случае - inventTrans увеличился с 13 гигабайт до 31. Это без индексов (а с ними так вообще).
Общий размер базы увеличился примерно в два раза.

А выравнивание у вас в какую сторону?
Стандартное для 4ки влево?
Если нет, то проведите выравнивание влево
http://axapta.mazzy.ru/lib/adjustment/

Цитата:

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

Есть ли у кого-то идеи - как отключить сию безусловно полезную в наших реалиях функциональность?

Нет.

Цитата:

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

В принципе, если переконвертить средствами СКЛ поле из nvarchar в varchar - Аксапта это проглатывает. Даже при синхронизации ничего не пытается переделать. Но как-то стрёмно, например если сменить EDT - возвращает обратно в nvarchar.

Не надо мучать кошечку.
После таких манипуляций никто не гарантирует работоспособность Аксапты.
Аксапта не работает правильно с NULL и не занимается интерпретацией результатов выражений с NULL-значениями.

[Garic]

Цитата:

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

А выравнивание у вас в какую сторону?
Стандартное для 4ки влево?

Да, безусловно, у нас изначально так было. Для InventTrans специально проверил - все поля влево.

Цитата:

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

Не надо мучать кошечку.
После таких манипуляций никто не гарантирует работоспособность Аксапты.

Кошечка сама виновата.
В чём сакральный смысл делать такие поля как dataAreaId, InventTransId, InventDimId, Voucher типом nvarchar ? Кому-то очень нужно вести их на китайском?
А база-то растёт, особенно индексы... И производительность...
Нет бы сделать чтобы это настраивалось на уровне EDT.
Когда база гигов 20-30, это не страшно. Но когда она 70 и увеличивается до 150, тут уже начинаеш задумываться - а нужна она, четвёрка?

Цитата:

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

Аксапта не работает правильно с NULL и не занимается интерпретацией результатов выражений с NULL-значениями.

А это к чему? Не понял.

[mazzy]

Сейчас названия компаний и префиксы-суффиксы в номерах лотов на китайском вполне допустимы.

Цитата:

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

А это к чему? Не понял.

Если я правильно понимаю, что вы хотите вручную изменить тип на тот, что может содержать null-значения. Аксапта же сейчас использует тип, который не может содержать Null.

[Vadik]

Цитата:

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

В чём сакральный смысл делать такие поля как dataAreaId, InventTransId, InventDimId, Voucher типом nvarchar ? Кому-то очень нужно вести их на китайском?

Это задел на будущее, чтобы версия 5.0 стала еще производительнее, не иначе

"Сейчас я рельсу брошу и ка-а-к побегу" (с) анекдот

[glibs]

Цитата:

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

...
Это задел на будущее, чтобы версия 5.0 стала еще производительнее
...

Это шутка, или действительно стоит ожидать возможности перехода на более короткие коды?

[Garic]

Цитата:

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

Это задел на будущее, чтобы версия 5.0 стала еще производительнее, не иначе

Надо побыстрее перейти на эту версию. Возможности албанского там будут существенно расширены.

http://blogs.msdn.com/mfp/archive/20...cs-ax-5-0.aspx

[Logger]

Цитата:

В чём сакральный смысл делать такие поля как dataAreaId, InventTransId, InventDimId, Voucher типом nvarchar ? Кому-то очень нужно вести их на китайском?
А база-то растёт, особенно индексы... И производительность...
Нет бы сделать чтобы это настраивалось на уровне EDT.
Когда база гигов 20-30, это не страшно. Но когда она 70 и увеличивается до 150, тут уже начинаеш задумываться - а нужна она, четвёрка?

Если честно вообще непонятно зачем такие внутренние идентификаторы как
InventTransId, InventDimId, Voucher сделали строками.

Нигде в системе не встречал чтобы пользователь работал с ними непосредственно или искал по ним данные (ну разве что по Voucher). Данные типы вообще напрашиваются чтобы быть int32 или int64

Как вариант можно попробовать прокодировать номерные серии для этих полей специальным управляющим символом '&' и сделать выравнивание по левому краю. В этом случае номер будет генериться используя не только цифры но и буквы латинского алфавита - медленнее будет нарастать число значащих цифр - меньше места будет занимать идентификатор в базе.

[kashperuk]

Думаю, это сарказм, но очень правдоподобный.

[glibs]

Цитата:

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

...
очень правдоподобный
...

Чтож, будем надеяться.

[Logger]

Цитата:

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

Чтож, будем надеяться.

Надежды мало :
http://dynamicsmatters.blogspot.com/...inventdim.html

Цитата:

Anonymous said...
>> Create an Array field InventCondition with three fields Batch, SerialNumber, and Condition

Do you plan to make this fields integer type, not string like in Ax3.0 ?

I think it can minimize size of indexes. Besides, DB perform operations with numbers much faster than with strings.

27 March 2008 00:32:00 PDT


Sven Jochimsen said...
I believe that it would be a hughe performance gain but also a hughe functional loss to only have numbers in all the references.

Plus converting existing data will be an even bigger job :-(

Best Regards
Sven

27 March 2008 09:46:00 PDT

[Alexius]

Для любителей серьезного экстрима и MS SQL 2000 могу предложить попробовать поменять местами varchar и nvarchar

sp_configure 'show advanced options', 1
RECONFIGURE WITH OVERRIDE
GO
sp_configure 'allow updates', 1
RECONFIGURE WITH OVERRIDE
GO
UPDATE systypes SET name = 'varchar2' WHERE name = 'varchar'
GO
UPDATE systypes SET name = 'varchar' WHERE name = 'nvarchar'
GO
UPDATE systypes SET name = 'nvarchar' WHERE name = 'varchar2'
GO

На первый взгляд работает.

PS. Обкатку это не проходило, за последствия не отвечаю

[Vadik]

Цитата:

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

Пока всё что нашёл - это ключ UNICODEENABLED в
SQLSYSTEMVARIABLES

ну еще как минимум STR=VARCHAR(%U) был в трешке
доберусь до четверки, проверю

[Garic]

Цитата:

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

ну еще как минимум STR=VARCHAR(%U) был в трешке
доберусь до четверки, проверю

Ага, ключевое слово "был"
Причём этот параметр даже работал - вчера проверил.

Щас такого параметра нет, пробовал его добавить - вдруг заработает - не прокатило.

Ещё нашёл параметр - если экспортнуть настройки сервера АОС в файл - "dbunicodeenabled,Text,1" - тоже не работает

[SolNik]

Поднимаю тему.
Есть ли у кого-то реальный опыт в 4-ке преобразования юникодовых полей в varchar?