У меня есть СТАРЫЙ сервер с DG / UX, который в ближайшем будущем не будет поддерживаться. У меня есть некоторые символьные формы оракула, которые необходимо перенести с этой машины. Кто-нибудь знает, какую стратегию миграции использует Oralce для обновления этих символьных отчетов. Это не обязательно должна быть самая новая версия, это даже не обязательно для версии с графическим интерфейсом, но мне нужно перейти на поддерживаемую ОС, такую как Linux.





Простой ответ - посоветовать вам проверить Миграция с 6i на 10g.
Сделав это раньше, я считаю, что гораздо более полезным ответом будет посоветовать вам переписать эти формы и отчеты с нуля. Вероятно, в другом инструменте - особенно если вы хотите иметь веб-интерфейс и т. д., Вместо того, чтобы вас мешала старая среда выполнения Java.
Существуют продукты, которые позволят вам перевести старый код форм в PL / SQL. Кумаран является примером одного из них, но я обнаружил, что он содержит ошибки, и мне пришлось много вручную редактировать код, чтобы заставить его работать так же, как оригинал.
Насколько я понимаю, CUI мертв, так что вы можете полностью перейти к графическому интерфейсу. В последний раз, когда я смотрел на него, почти не было документации для форм CUI, и часто вещи, которые работали в графическом интерфейсе, вообще не работали в CUI.
При преобразовании приложений форм на основе CUI в графический интерфейс вы можете столкнуться с некоторыми проблемами.
Иногда выполняется проверка и специальная обработка, когда пользователь переходит к следующему или предыдущему полю / блоку / и т. д. Когда вы переключаетесь на правильный графический интерфейс, ваш пользователь может пропустить эти события, просто щелкнув другое поле. Таким образом, у вас остается два варианта - №1 проверить все формы или №2 отключить навигацию в форме с помощью мыши.
Вариант №1 требует меньше усилий, чем перепланировка, но посмотрите, сколько работы мы уже вложили в него.
Вариант №2: ваши пользователи будут вас ненавидеть и будут преследовать вас с вилками и факелами. Они поймут, что у них нет ничего ценного за всю вашу работу. Тогда вы все равно выберете вариант №1.
Иногда пользовательский интерфейс, который отлично работает (или требуется ограничениями) CUI, просто неверен и нарушает метафору пользовательского интерфейса, с которой пользователи привыкли работать в остальной части графического интерфейса (например, всплывающее окно со списком что вам нужно выбрать запись, а не раскрывать, где вы можете просто выбрать правильное значение напрямую)
При преобразовании в графический интерфейс CUI может иметь другие шрифты, размеры текста и другие параметры форматирования по умолчанию, чем только что написанная форма (для меня это было так). Итак, теперь либо весь набор форм должен быть обновлен в соответствии с новой темой Oracle по умолчанию для форм / отчетов, либо каждая новая форма / отчет должна вернуться к старому неуклюжему стилю, который у вас был раньше, - или он будет торчать, как больной палец. (и ваши пользователи захотят, чтобы они все теперь были похожи на этого симпатичного).
Не тот ответ, который вы хотели; Хм. Но вы можете использовать это как предлог, чтобы отказаться от обновления беговой дорожки Forms / Reports и, возможно, даже убрать некоторые хаки, которые должны были произойти за эти годы.