Миграция AX3(Oracle) -> AX2009(MSSQL)

[Shamil]

Цитата:

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

И еще совет - если будете переходить - то делайте переход в 2 этапа - сначала базу перенесите с Oracle на MS SQL (оставшись в 3.0), затем сделайте апгрейд с 3.0 на 2009. Одновременно это сделать не получится, а с апгрейдом "ораклиных" данных вы ой как намучаетесь... Но формально - обновить "ораклиные" данные можно (штатными средствами, заранее имея карту разбросанных граблей)

Мы как раз пришли к выводу, что сделать будет надо в два этапа, но мы думали об обратном порядке: сначала апгрейд, затем перенос базы (если не отговорим). А о каких граблях идет речь? И воообще, что там в базе Аксапы лежит кроме таблиц? Констрейнты, индексы, триггеры, процедурная логика?

И еще вопрос:
Практикуется ли кастомизация Аксапы на уровне базы данных? Т.е. бывает ли необходимость дописывать процедуры, добавлять свои таблицы и т.п.?

[sukhanchik]

Цитата:

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

А о каких граблях идет речь? И воообще, что там в базе Аксапы лежит кроме таблиц? Констрейнты, индексы, триггеры, процедурная логика?

Скажу по опыту апгрейда данных на оракле с 3.0 на 4.0
1. Подключение к схеме (БД) источнику и схеме (БД) приемнику утилитой AxdbUpgrade.exe осуществляется по-разному (имеется в виду - в одном случае нужно задавать логин/пароль, в другом - создавать d jhfrkt логин автовхода типа OPS$WINUSER (я уж не помню как он там в оракле зовется), причем доступ должен иметь как логин из под которого инсталлятор работает, так и логин, который собсно переливает данные.
2. После создания схемы - ее должен "окучить" инсталлятор аоса, т.к. он там создает невалидные хранимые процедуры, которые другим путем сложно создать. Соответственно, при желании "повторить" процедуру закачки данных - надо будет заново ставить аос.
3. Сам файл AxdbUpgrade.exe который шел в штатной поставке - был неработоспособен с ораклом (уже не помню какие были проблемы - но помню что мы запрашивали из МС новый файлик)
Вроде так все... но помню - что убили порядка 3-х человеко-месяцев на выработку процедуры перехода (применительно конечно к компании, в которой осуществлялся переход) с 3 тестами получения данных.

Цитата:

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

И еще вопрос:
Практикуется ли кастомизация Аксапы на уровне базы данных? Т.е. бывает ли необходимость дописывать процедуры, добавлять свои таблицы и т.п.?

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

[BOAL]

Лучше именно оставаясь на Ах3 перейти на сиквел, а потом уже на ах2009
На то есть причины
1. Инструкция по конвертации данных для неизменяемого приложения
2. Перенос на новую АХ штатно, без проблем с данными (новых дополнительных проблем, разумеется )

Просто бытует мнение, что со старших версий АХ перестает дружить с Оракл все больше и больше, и переходя на ах2009 с ораклом, можно найти кучу новых грабель, которых просто не будет, если не создавать эту связку.

Знаю проект, где так и пошли - перешли с АХ4+оракл на АХ4+скл2008 для будущего перехода на ах2009
И еще, меж этими этапами может пройти некоторое время (с продолжением работы уже на скл)

=====
Поддержу вариант:
1. Оставить Ах3+ оракл в покое (как архив)
2. перенести код на АХ2009 с рефакторингом и пересмотром потребности (лишнее потереть, тк время же прошло - заплатка на заплатке может быть)
3. залить начальные данные в ах2009+скл и работать по-новому