Переезд с Navision 3.70B на 4.0

[foxsoft2005]

Всем привет!
В общем, проблема такая:
Есть некий клиент, у которого стоит Nav 3.70b. Эта версия была довернута до нужного ему (клиенту) состояния (читай - доработана ). Теперь клиент хочет, чтобы ему поставили "четверку", но основным условием является то, что весь доработанный функционал+данные должны быть доступны в новой версии.

Собссно, вопрос - а реально ли совершить такого рода переезд?

P.S. Имеется ввиду НЕ банальная конвертация БД с "тройки" на "четверку", а ПЕРЕНОС функционала и истории с одной БД на другую.

Заранее спасибо за ответы.

[Yuriy]

Извините, а неужели бывает банальная конвертация и перенос данных? Я в свое время занимался переносом с 3.60 на 3.70, ушло порядка 2 недель только на перенос функциональности, плюс еще 2 недели на доводку и исправление возникших неурядиц с данными.

Какой объем модулей, используемых клиентом в системе? Сколько было сделано доработок?

И еще, это нормальная ситуация

[Sitizen]

Собственно процент реальности этого обратно пропорционален проценту модификаций стандартного функционала.

Процедура приблизительно следующая: ставишь Девелопер тулкит. Загружаешь в него базы:
1. 3.70В НЕ модифицированную;
2. 3.70В модифицированную;
3. 4.00 не модифицированную
Потом запускаешь процедуру мерджа и смотришь, что получилось. Весь модифицированный код придется проползти ручками и поправить если что прямо там в Тулките. Потом выгружаешь полученные объекты и накатываешь на, естественно стачало тестовую базу, гоняешь ее, потом уже на рабочую.

[foxsoft2005]

Цитата:

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

Весь модифицированный код придется проползти ручками и поправить если что прямо там в Тулките.

А как править прям в тулките объясните для балбеса? Я его рыл и не нашел там
P.S. Спасибо за советы.
P.S.S. В общем-то функционала ДОписано довольно много, правились и кодюниты и таблички стандартные многие.. В обсчем - надо попробовать реализовывать советы.

[Sitizen]

Цитата:

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

Собственно процент реальности этого обратно пропорционален проценту модификаций стандартного функционала.

Процедура приблизительно следующая: ставишь Девелопер тулкит. Загружаешь в него базы:
1. 3.70В НЕ модифицированную;
2. 3.70В модифицированную;
3. 4.00 не модифицированную
Потом запускаешь процедуру мерджа и смотришь, что получилось. Весь модифицированный код придется проползти ручками и поправить если что прямо там в Тулките. Потом выгружаешь полученные объекты и накатываешь на, естественно стачало тестовую базу, гоняешь ее, потом уже на рабочую.

Там после мерджа открываются сразу четыре окна рядом, в таком же порядке, как я описал перед этим, и четвертая - новая. Там есть какие-то праметры мерджа, я если честно не помню, все в визарде. Так вот в четвертом окне можно сразу править - там так получается, что видно сразу параллельно: что было в немодифицированной базе, как это исправилось, что стало в новой версии и что получилось в последней базе после сливания всего этого. Сопоставление идет по номеру строки кода.
Если Вы делали когда-нить сравнение кода, то тут очень похоже, только вместо двух окон - четыре.

[foxsoft2005]

Цитата:

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

Цитата:

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

Собственно процент реальности этого обратно пропорционален проценту модификаций стандартного функционала.

Процедура приблизительно следующая: ставишь Девелопер тулкит. Загружаешь в него базы:
1. 3.70В НЕ модифицированную;
2. 3.70В модифицированную;
3. 4.00 не модифицированную
Потом запускаешь процедуру мерджа и смотришь, что получилось. Весь модифицированный код придется проползти ручками и поправить если что прямо там в Тулките. Потом выгружаешь полученные объекты и накатываешь на, естественно стачало тестовую базу, гоняешь ее, потом уже на рабочую.

Там после мерджа открываются сразу четыре окна рядом, в таком же порядке, как я описал перед этим, и четвертая - новая. Там есть какие-то праметры мерджа, я если честно не помню, все в визарде. Так вот в четвертом окне можно сразу править - там так получается, что видно сразу параллельно: что было в немодифицированной базе, как это исправилось, что стало в новой версии и что получилось в последней базе после сливания всего этого. Сопоставление идет по номеру строки кода.
Если Вы делали когда-нить сравнение кода, то тут очень похоже, только вместо двух окон - четыре.

Суть понятна. Вероятно, очень похоже на Стартим или VSS. Еще раз спасибо!

[Marisha]

Добрый день,
у меня похожая задача...

необходимо провести миграцию БД с версии 3.60 на 4.0... БД на SQL. Данные, объекты, код, БД была дополнительно модифицирована, т.е. не стандарт...

К своему стыду никогда этого раньше не делала...
По поводу объектов более мение понятно... а как на счёт истории? как загрузить данные? ДатаПорты? врятли...

Может есть где-нибудь описано этого процесса?

Какие могут появиться проблемы?

Спасибо!

[Sitizen]

Marisha, если есть сомнения, то лучше доверить этот вопрос професиионалам, т.к. это не та задача, на которой можно научиться. Здесь нужно делать все наверняка. И лучше всего, чтобы обновление делал человек, который в курсе модификаций.

Что касается данных, то их никуда переносить не нужно, просто полученные новые объекты импортируются в старую базу и она продолжает работать, только уже по новому.

[Marisha]

Я не являюсь новичком в Navision :-) Просто раньше не приходилось этого делать в таком виде: какие есть модификации известно только на уровне Юзера, т.е. надо чтобы было так и так, а вот как это реализовано никому неизвестно.
В принципе у меня есть представление что нужно делать, но хотелось бы знать как это сделать найболее оптимально и граммотно. Какова последовательность действий?
как описано выше готовлю объекты,
импортирую их в БД 3.60 (а как с объектами которые не поддерживает 3.60? menu, xml... )

делаю backup БД 3.60 и restore в БД 4.0
или
просто пытаюсь открыть эту базу уже с версией 4.0 ?

[Sitizen]

Если честно, то я делал обновление один раз всего - с 3.6 на 3.7
Что касается четверочных прибамбасов (меню и все остальное) то думаю, что достаточно будет просто открыть базу клиентом четверки и обновить ее по запросу.
Но лучше все делать сначала на тестовой базе а потом на живой.
Я бы сделал следующим образом:
1. сформировать объекты новой базы - это то, что я писал ранее;
2. развернуть полноценную копию (полноценную, в том смысле, что если у вас база на SQL, то и копию на SQL и желательно на сервере с теми же характеристиками или на том же, если Натив, то такую же)
3. собственно обновление базы:
а. открыть копию клиентом 4.0, он спросит обновить или нет, нужно обновить;
б. накатываем на базу новые объекты;
в. всесторонние тесты;
4. проделываем все для рабочей базы с учетом уже конечно исзменений и исправлений, выявленных при тестировании.
На рабочей базе начинать делать все лучше всего в пятницу вечером, чтобы была возможность песпрепятственной работы в течении выходных. И обязательно перед каждым новым этапом обновления делать бэкап.

[Marisha]

Спасибо огромное!!! это как раз то что мне было нужно.
Буду пробовать.

[Sitizen]

Вероятно, что и с данными придется повозиться. Но чтобы сказать точно, нужно знать базу и доработки все.
Просто пришло в голову, что вполне может быть такое, что дописали некий функционал, которого не было в 3.7, нопоявился в 4.0, и при решении перейти на стандарт, придется переносить и данные из одного места в другое.
С отчетами тоже наверняка может проблема возникнуть.

Это что еще пришло в голову.

Ну в общем, желаю удачи

[foxsoft2005]

Спасибо! В общем - будем работать в усиленном режиме .

[Галина]

Цитата:

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

Что касается данных, то их никуда переносить не нужно, просто полученные новые объекты импортируются в старую базу и она продолжает работать, только уже по новому.

Хм-я что то не понимаю.
А как же конфликты полей?

[foxsoft2005]

Цитата:

Сообщение от Галина

Цитата:

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

Что касается данных, то их никуда переносить не нужно, просто полученные новые объекты импортируются в старую базу и она продолжает работать, только уже по новому.

Хм-я что то не понимаю.
А как же конфликты полей?

Дык ручками их, ручками

[Галина]

Ручками?????

[foxsoft2005]

Цитата:

Сообщение от Галина

Ручками?????

Тогда поясните, что Вы имеете ввиду? Примерчик там...

[Marisha]

Пока только анализирую, но уже есть пр-р:

Navision 3.60 T18 Customer: поле 116: Allow Payment Tolerance Boolean
Navision 4.0 T18 Customer: поле 116: Block Payment Tolerance Boolean

Получается, нужно будет менять значение на противоположное...? Может не ручками, но что-то вроде того...
И кто знает есть ли ещё и где подобные несоответствия данных...

[Sitizen]

Цитата:

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

Пока только анализирую, но уже есть пр-р:

Navision 3.60 T18 Customer: поле 116: Allow Payment Tolerance Boolean
Navision 4.0 T18 Customer: поле 116: Block Payment Tolerance Boolean

Получается, нужно будет менять значение на противоположное...? Может не ручками, но что-то вроде того...
И кто знает есть ли ещё и где подобные несоответствия данных...

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

[foxsoft2005]

Цитата:

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

Пока только анализирую, но уже есть пр-р:

Navision 3.60 T18 Customer: поле 116: Allow Payment Tolerance Boolean
Navision 4.0 T18 Customer: поле 116: Block Payment Tolerance Boolean

Получается, нужно будет менять значение на противоположное...? Может не ручками, но что-то вроде того...
И кто знает есть ли ещё и где подобные несоответствия данных...

Еще самый простой пример - это поле "BoE No." и "BoE Line No." в NAV360 (они же "CD No." и "CD Line No." в NAV40 SP3)... Ну и таблички, соответственно.. "Bill Of Exchange Line" -> "Custom Declaration Line"...

Может это и не конфликт в понимании слова - но при переносе функционала ох как жисть может подпортить...