Импорт 2.5 - 3.0

[Vadik]

Потихонечку переходим на 3.0. Поставил ее рядом (и БД, и приложение отдельно от 2.5, данные из компаний заэкспортировал в файлы), переношу обновления в application, решил данные в 3.0 импортировать - ан нет

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

Что за нафиг? Что мешает данные втянуть? Что, при каждом импорте код не только преобразует данные, но и структуру меняет?

Не могу понять.. Теперь что, все через Excel переносить?

[Антон Солдатов]

попробовал - действительно впечатляет.. единственное что сразу пришло в голову.. это делать полный дубликат базы.. запускать на нем отдельную 2.5 и обновлять до 3.0... Это криво конечно, но думаю удобнее чем Excel...

[mazzy]

Хм... читайте рекомендации от МСБС.
если у вас их еще нет, то обратитесь к вашему партнеру или в МСБС к Михаилу Мозгову.

И еще. Опыт подсказывает, что лучше пользоваться не импортом, а подсовывать в 3.0 базу от 2.5. Тогда процедура апрогейда проходит легче. К тому же виртуальные компании только так и можно поднять.

[Vadik]

Цитата:

Хм... читайте рекомендации от МСБС.

Это Modification Transfer.chm?

Обновление данных в Axapta 3.0
При переходе с одной версии Axapta на другую или при установке новых пакетов обновления (Service Packs, SP) изменяется структура данных системы Axapta. В связи с этим возникает необходимость привести данные, накопленные при работе с предыдущими версиями Axapta, в соответствие с обновленным словарем данных.

В версии Axapta 3.0 существует механизм, обеспечивающий автоматическое преобразование данных. Этот механизм срабатывает в следующих случаях:

-В случае выполнения Контрольного списка установки (в английской версии Upgrade Check List)
-При импорте данных в систему.

Или опять не те мануалы курю? Ни слова о количестве компаний

Цитата:

И еще. Опыт подсказывает, что лучше пользоваться не импортом, а подсовывать в 3.0 базу от 2.5

Я вчера вечером так и сделал. Поднял рядом копию базы от 2.5 и натравил на нее application от 3.0. Компиляция шла часа четыре, надоело ждать, поехал домой. Сегодня приезжаю - машина перезагрузилась и снова при запуске предлагает откомпилироваться. В общем, решил, что проще все же проапгрейдить application от 2.5, экспериментировать потом буду

[mazzy]

Ой. Не туда написал...

Да, я имел в виду этот и презентацию Мозгова, которую он показывал на семинаре для партнеров.

[Small Den]

Странное это дело ... автоматическое обновление данных.
Установил отдельно приложение и клиента Axapta 2.5 c SP5 HF1. В приложении есть клиентские модификации. Далее, следуя инструкции по установки, произвел обновление до версии 3.0. Удалил все индексные файлы и настроил конфигурацию для двухуровневого клиента на обновленное до версии 3.0 приложение и базу данных от 2.5. После запуска и завершения процесса индексирования, система выдала ошибку sql: "Invalid field: REPORTTOPMARGIN" затем приглашение ввести пароль и затем целую кучу других ошибок sql. В результате - клиент зацикливается на одной и той же ошибке. Разумеется, при этом ни о каком "Контрольном списке установки" и автоматическом обновлении данных речи быть не может. Если подсунуть ей пустую базу, то все запускается на ура.

Где может скрываться ошибка и как ее обойти?

[BOAL]

При переносе данных с версий 2.5 младше СП4 вообще много трудностей.

Мне успешно удалось перенести данные с SP2HF1
Но методика переноса была практически ручной - пришлось писать много оброботок старых данных (некоторые таблички заливались только из csv).

В результате получились в 3.0 полностью живые данные:
корректные остатки по складским и фин. аналитикам (конфигурация теперь ведь аналитика),
перестройка старой кассы в новую позволила формировать кассовую книгу и получать в АО под отчет старые остатки,
заказы и закупки могут формировать фактуры по старым данным для новых книг продаж\покупок,
договора (проектная модификация) перенеслись в договора от ах30

На данный момент идет отладка модуля ОС, тк в ах30 появились модели учета, которых не было ранее и данные не "оживают" сами.

Очевидно, что перед переносом данных, приложение было приведено в соответствие проектным модификациям.

[OliaM]

Процедура автоматического обновления данных не работает толком. Расскажите, пожалуйста, кто как боролся с переносом своих данных из 2.5 в 3.0 в модифицированном приложении?

У меня такое ощущение, что невозможно будет обойтись только стандартной процедурой обновления.

[AKIS-Falcon]

Во-первых: какие точно у вас версии 2.5 и 3.0 (сервис-паки...).
Во-вторых: насколько сильно модифицированы таблицы (сколько таблиц модифицировано в %, в каких слоях...)?

В приниципе, если автоматически перенести данные не удается, можно это делать руками. Аксапта позволяет выгрузить таблицу в виде csv файла (в 2.5 это будет Эксель файл, который потом легко конвертится в csv), а потом определить, какие колонки файла соответствуют каким полям таблицы... Минус - в этом случае вы скорее всего потеряете RecId, кроме того, придется все перегружать столько раз, сколько у вас компаний...

Есть второй способ, требующий от вас хорошего знания баз данных. Техническая реализация зависит от того, используете ли вы Оракл или сиквел-сервер, дальнейшее относится только ко второму варианту. Обе базы, 2.5 и 3.0 желательно иметь на одном сервере. Настраиваете репликацию между базами, потаблично, при необходимости указываете соответствие полей. Удается сохранить рециды,и перенести все за раз, к тому же быстрее работает.

Как после первого, так и после второго варианта, разумеется, нужно запускать процедуры конвертации. Но это, увы, отдельная песня....

И еще, совет из разряда "маленькие хитрости". Если стандартный мастер переноса у вас сбоит - попробуйте поискать таблицы, в которых есть записи с 0 Recid. Аксапта 3.0 таковые очень не любит, поэтому их нужно перенумеровать, задав номера -1, -2, -3 и т.д (они будут автоматически превращены в "максимальный номер -1", "-2" и т.д., так что нет риска создать записи с неуникальными RecId).

Мы проводили процедуру переноса и конвертации сами, с 2.5 Sp2 на 3.0 SP2, все международное... Проблемы были с InventTable, все остальное перенесло более-менее в штатном режиме. Доработок у нас много...