Перенос объектов DAX4 в DAX5

[IvanS]

Подскажите пожалуйста, как лучше переносить наработанный функционал из 4 в 5. Может технология какая есть? А то кроме как простого переноса слоя из 4 в 5 я не вижу и наверняка будет большое количество ошибок

[S.Kuskov]

Технически это ещё реализуемо через XPO (экспорт/импорт). Но если вы хотите перенести весь функционал, то слоем гораздо быстрее.

Но на самом деле абсолютно не важно каким образом в новой версии появятся ваши наработки. В любом случае прийдётся делать сравнение слоёв и отрабатывать пересечения.

[IvanS]

Цитата:

то слоем гораздо быстрее

Есть быстрая возможность это сделать кроме как добавить с помощью фильтра в проект все объекты с нужным слоем?

[S.Kuskov]

Цитата:

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

Есть быстрая возможность это сделать?

сделать что?

Слои хранятся в файлах *aod на файл-сервере приложений. Чтобы перенести изменения нужно скопировать этот файл в папку с новым приложением.

[S.Kuskov]

А для экспорта в *.xpo не обязательно создавать проект. На самом диалоге экспорта есть параметр 'Слой прикладных объектов'. Если его использовать, то выгрузятся только те объекты, которые присутствуют на выбранном слое. Но скопировать целиком слой всё же проще.

[IvanS]

Цитата:

Сообщение от S.Kuskov

А для экспорта в *.xpo не обязательно создавать проект. На самом диалоге экспорта есть параметр 'Слой прикладных объектов'. Если его использовать, то выгрузятся только те объекты, которые присутствуют на выбранном слое. Но скопировать целиком слой всё же проще.

Но на сколько правильно будет это делать? Для одинаковых версий без разницы, но в 4 и 5 наверняка есть различия поэтому я пока через экспорт попробую

[S.Kuskov]

Цитата:

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

Но на сколько правильно будет это делать?

Прежде чем что-либо делать я бы рекомендовал вам ознакомится с инструкцией http://go.microsoft.com/fwlink/?linkid=103943

[sukhanchik]

А как Вы еще хотели переносить функционал? Естественно будет куча ошибок. И какая может быть технология? Технология может еще быть при переносе данных между 4 и 5. При условии стандартного функционала.
А так - как система догадается, что (к примеру) какая-нибудь Ваша функциональность соответствует существующей в 2009?

Т.е. Экспорт/Импорт (2 раза подряд), а затем сравнение слоев, исправление ошибок компиляции, тестирование функционала и т.д.

[IvanS]

Цитата:

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

А как Вы еще хотели переносить функционал? Естественно будет куча ошибок. И какая может быть технология? Технология может еще быть при переносе данных между 4 и 5. При условии стандартного функционала.
А так - как система догадается, что (к примеру) какая-нибудь Ваша функциональность соответствует существующей в 2009?

Т.е. Экспорт/Импорт (2 раза подряд), а затем сравнение слоев, исправление ошибок компиляции, тестирование функционала и т.д.

А зачем 2 раза? чтобы он автоматически компилировал?

[S.Kuskov]

Цитата:

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

А зачем 2 раза?

Ипорт является однопроходным. Некоторые свойства импортируемых объектов могут ссылатся на другие, пока ещё не импортированные объекты. При импорте вместо таких значений вставляются заглушки. И связь между объектами разрывается. Повторный импорт исправляет эту ситуацию.

Упс, опередили

[sukhanchik]

Потому что увы - это еще осталось с 3-шки (как бы Микрософт не уверял что это починил - неоднократно это случалось на 4.0 SP2) - первый раз не все корректно импортнется. Т.е. есть у Вас расширенный тип (к примеру), у которого есть ссылка на таблицу. А таблицы в момент импорта еще нет (она загрузится после EDT). Получится корявая ссылка. У меня получалось наоборот (4.0) - когда в XPO присутствует новая таблица и новый EDT - то после импорта вылетают сообщения - что-то типа "У поля такого-то неизвестный тип данных" - т.е. такое ощущение - что таблица загружается раньше. Повторный импорт исправляет эту ситуацию - т.к. тип уже известен, таблица уже известна и т.д.

[Alexanderis.ua]

Не знаю актуально ли еще.

Мы при переносе использовали следующую схему:

Пообъектно выгрузилось все, что менялось нами на 4-ке.
Потом эти же объекты выгружались из стандартной 4-ки и стандартной 5-ки.

Потом использовали утилиту для сравнения (KDiff) с участием всех трех вариантов.
Довольно много конфликтов разрешилось автоматически. Остальные уже ручками.

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

[BOAL]

Можно слои 4и класть в папку олд или иметь две системы запущенные и сравнивать дельту своего на 4е, что б понять, что нужно на 2009 менять.
Можно проект разницы по ОЛД строить, чтоб отсечь элементы, которые не менялись вообще и потому их можно не проверять в модификациях.

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

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

[S.Kuskov]

По поводу модификации утилиты сравнения. Ещё одна идея к реализации.

При сравнении монолитных объектов (form, report) все изменения можно увидев сопоставив последний и предпоследний слой (и как BOAL точно заметил удобно было бы "... чтоб она при открытии нужные слои сразу ставила ...").
Но таблицы или классы, а точнее их методы, могут перекрываться слоями частично. Т.е. если на каждом новом слое к объекту добавлялся новый метод и на последнем слое были сделаны изменения во всех методах, то для того чтобы увидеть все перекрытия нужно сравнить последний слой со всеми предыдущими по очереди.
А хотелось бы иметь возможность построить сравнение последнего слоя с результатом слияния всех предыдущих слоёв.

Может быть я что-то упустил и это возможно в стандарте?

[BOAL]

Не понял логики
Если говорить о многослоистом сравнении (стандартная АХ - куча слоев и пусть ваш код в 2 слоях (у мя в 3х)).
Сравнивать нужно последний слой родной АХ с последним своим
Вы ж уверены в своих слоях? И если там разница, то она нужна.
Так же и в стандарте - нужен последний слой, тк он и есть текущий СП
Если какой класс сидит в 5 слоях через 1 метод в разных, то выбор двух слоев сравнит все в них, а если чего в них нет, то на слой ниже от него.