mediumот файла fmb, в котором ни один модуль не скомпилирован?
а зачем?

А так, легко. Если форма хоть раз запускалась, скомпилированные модули уже содержит. IMHO

mediumВопрос: А зачем? Ответ: Билдер ведёт себя существенно по-разному при открытии формы, в которой ничего не скомпилировано, и при открытии формы, в которой есть скомпилированные модули. Некоторые разработчики встречали эти отличия в своей практике. И некоторые ситуации им не вполне нравятся. И хочется избежать этих ситуаций.

Можно подробнее.
Обычно Ctrl+T (compile all) вполне достаточно
На проекте со своими формами, у нас перекомпиляция всей системы (библиотеки+потом формы) перед деплоитментом была вынесена отдельно и выполнялась через пакетный запуск ifcmp60.

medium...
Таким образом - форма запускалась, но, как мне кажется, не содержит скомпилированных модулей....
Таким образом, как мне кажется, утверждение неверно...
Опять таки возврашаясь к вопросу "Зачем?".
1) Если нужно убедиться, что все скомпилировано правильно - Ctrl+T или ifcmp60
2) Если нужно удалить программный код, то например описанный Вами выше сценарий (но я бы этим не увлекался)
Но зачем знание, содержит или не содержит? )))

Насколько я помню, даже Forms/Open API никаких функций работы со скомпилированным кодом не имеет. Можно, конечно, попытаться сконвертировать форму в txt формат и в нем поисках записи добавляемые после перекомпиляции.... но осмысленность данного действия для меня не очень понятна.

В 6.0 / 6i действенный способ "лечения" формы (иногда бывает необходимо) мне известен только один. Создать новую форму и через клипбоард скопировать все из старой в новую. (но слетит наследование)

В версиях после 9, можно попытаться экспортировать в xml и потом импортировать обратно. Но даже тут бывают засады. Не все возможности/атрибуты формсов в xml сохраняются ((( Сталкивался, что часть информации пропадала, но подробностей уже не помню.

IMHO & AFAIK

medium...
Альтернативным половинчатым решением проблемы может явиться наличие инструмента, осуществляющего пакетное преобразование набора форм в файлах FMT в формат FMB

Известно ли что нибудь о таком интрументе?

google найдется все.....

https://www.google.ru/search?q=Forms batch FMT converting&oq=Forms batch FMT converting

первые же ссылки
http://www.orafaq.com/maillist/oracle-l/2002/07/10/0710.htm

Amar Kumar Padhi <TS2017_at_emirates.com>Thanks everybody.
To create FMT from FMB

ifcmp60 userid=<..> module=abc.fmb script=yes

To convert FMT to FMB

ifcmp60 userid=<..> module=abc.fmt parse=yes

rgds
amar
http://amzone.netfirms.com < http://amzone.netfirms.com/>

mediumЭкспортировать в xml нет небходимости, поскольку есть формат FMT.

AFAIK

По опыту работы в Forms 6.0 / Forms 6i, при переносе сглючившей формы в FMT и обратно, форма востанавливается "как была", а не пересоздается заново. Пару раз сталкивался со сглючившими формами, конвертация в FMT и обратно, первое, что приходило в голову... но нифига не помогало. Только или создавать новую форму и перетаскивать элементы через клипбоард или пересоздавать форму через XML (но это нужен Forms >= 9).

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

medium....понять: есть ли риск, что после .... форма будет открыта билдером....
Знаю только одну ситуацию, когда билдер (и репортс) могут падать при открытие - "различные NLS_LANG". Но вообще, что бы билдер отказывался открывать формы - не сталкивался.

Для Репортсов только неделю назад сталкивался. Отчет создан в 1251, а открывается при UTF8 - Reports просто падает.

Лет 15 назад переводил приложение на Unicode, и с Forms 6i у меня приложение работало стабильно (1251 + UTF8), но специально ради этого ставил патчи и разработку всегда вел только в 1251, под UTF8 только компилировал проект. Вроде на начальном этапе проблемы были, но потом принаровился и все стало стабильно и без проблем.

mediumВерсия 10G.

Ничего не могу сказать. Опыта работы нету (((. Плотно работал только с 6i
На уровне халтуры сталкивался, но не больше (((

mediumА по поводу " пересоздавать форму через XML"

Тектовый формат. Работает так же как и FMT, только если FMT странный и нечитабельный форат, то XML нормальный формат в котором все понятно и его можно даже самому понимать/править (если нужно).

Есть команда комвертации формы из FMB --> XML, есть команда конвертации обратно XML -> FMB

Вроде на 10 g приходилось этим пользоваться, т.к. не поборол NLS_LANG. Разработку/халтуру вел на Windows (1251), деплоилось на Unix (ISO). При просто копировании и компиляции формы, русские буквы получались крякозябрами. Приходилось на Windows перегонять FMB->XML, на Юних перегонять обратно XML->FMB. По дороге лечилась кодовая страница и русские буквы начинали показываться корректно.

Так же, вроде сталкивался, что какой-то атрибут перетаскивался не полностью ((( приходилось руками (скриптом) XML файл доправлять ((( Но это была халтура, т.ч. ни на металинке проблему не смотрел, ни патчей не ставил.

Сейчас на работе установлен только Forms 6i и Reports 12, т.ч. по Forms 10 ничего подсказать не смогу

mediumЯ тут написал немного туманно:
Правильно читать: Надо понять: есть ли риск, что после изменения состояния "правильной базы" билдер не сможет открыть форму?
(Билдер может прекратить работу при попытке открытия скомпилированной полностью или частично скомпилированной формы, если в форме указаны объекты, не присутствующие в той базе данных, к которой установлен коннект. Если коннект не установлен, то тоже прекращает работу. И только, если установлен коннект и в базе есть нужные объекты - билдер благополучно открывает форму. Билдер завершает работу с таким сообщением : программа выполнила недопустимую операцию и будет закрыта.)

Ни разу с таким поведением не сталкивался. Но с 10 версией плотно не работал.

Если такое поведение действительно на проекте часто происходит, то использовать FMT / XML файлы по назначению ))), хранить проект в системе контроля версий CVS / SubVersion в виде FMT, XML файлов. Лучше в XML, т.к. по крайне мере, содержимое XML можно понять и не открывая форму в билдере. И написать скрипты, которые из исходных кодов будут собирать рабочую бинарную версию под конкретного заказчика. Своего рода build server.

Исходные коды (XML) - отдельно, в системе контроля версий; бинарные коды для деплоя заказчику (FMX, и даже FMB) - отдельно, после сборки проекта на конкретной схеме базы.

В системе контроля версий лучше хранить XML. Тогда, по крайне мере, можно будет сравнивать файлы разных версий между собой. И даже пытаться проводить merge разных версий/бранчей.

IMHO. Чисто теоретически. Как организовать такую структуру: разработчик - система контроля версий - build проекта - деплой - разработчиский/тестовый/промышленный инстанс удобным для разработчиков виде, это уже другой вопрос.

mediumА по поводу XML у меня остался вопрос: Для того, чтобы конвертнуть форму в XML - какой инструмент следует запускать? какой файл давать на вход этому инструменту?
надо смотреть доку.
Поскольку у меня сейчас под рукой 10-х формсов нет, то мне не проверить.

https://www.google.ru/search?q=oracle forms fmb to xml
https://docs.oracle.com/cd/E14373_01/migrate.32/e13368/appmgr_forms.htm#CHDFHAHA