Методы отладки приложения в Forms
ДИАГНОСТИКА FORMS

1 октября 2000 г.

Пэм Геймер,
Корпорация Oracle

FORMS TROUBLESHOOTING, by Pam Gamer

Доклад на конференции OOW-1999 (402.pdf)

ВВЕДЕНИЕ

Выяснение источника ошибок во время выполнения формы для новичка в Oracle Forms может стать чрезвычайно сложным делом. Большая часть работы по решению таких проблем заключается в идентификации источника и причины ошибки; и как только эта задача разрешается, исправление кода проходит относительно просто. Иногда даже опытному программисту трудно определить в форме с несметным числом триггеров различных уровней, который из операторов кода становится причиной порождения неожиданных результатов или сообщений об ошибке во время выполнения программы.

Существуют различные приемы, помогающие в таких случаях. Некоторые из них довольно простые, и их можно быстро претворить в жизнь; другие требуют использования отладчика Forms; где-то потребуется создание и интерпретация журналов. Большинство обсуждаемых приемов применимы к приложениям клиент/сервер, так как перед их развертыванием в Web-форме должно проверить на правильность работы в режиме клиент/сервер. Но кроме того, будут приведены некоторые приемы, применимые только к Web-формам. Если вы познакомитесь со всеми этими приемами, то в любой ситуации сможете быстро выбрать соответствующий инструмент для разрешения проблемы.

БЫСТРЫЕ МОДИФИКАЦИОННЫЕ МЕТОДЫ ДИАГНОСТИКИ

[Прим. редактора: В оригинале “QUICK AND DIRTY” - то есть "Быстрые и грязные", что по русски звучит не очень гладко. Автор скорее всего имеет в виду, что при применении этих методов приходится вносить в исходный текст отладочные модификации, то есть "грязнить" код.]

Некоторые методы определения проблем являются и быстрыми, и простыми в реализации. Они подходят главным образом для ситуаций, когда вам уже довольно понятно, в чем корни проблемы. Большинство этих подходов совершенно не сложны, но им не хватает мощности более формальных методов. В этом разделе обсуждаются четыре приема: комментирование части кода (превращение его в комментарий), использование встроенной команды "message", использование во время выполнения опции "debug_messages=yes" и, наконец, использование встроенной команды “break”.

КОММЕНТИРОВАНИЕ ПОДОЗРИТЕЛЬНЫХ СТРОК ПРОГРАММЫ

Если у вас возникло подозрение, что некоторые строки программы могут вызвать проблемы, попробуйте убрать их, превратив (на время) в комментарий, и проверьте форму снова. Комментарии – это невыполнимые части программы, которые в PL/SQL обозначаются одним из следующих способов:

строки, которым предшествуют два знака минус (--) или

часть кода, начинающаяся с /* и заканчивающаяся */

Если Вы закомментируете триггер или программный блок полностью, вам нужно оставить, по крайней мере, пустой оператор: null;

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

ИСПОЛЬЗОВАНИЕ ВСТРОЕННОЙ КОМАНДЫ “MESSAGE”

Встроенная команда "MESSAGE", помещенная в нужном месте, позволит вам выводить на экран любое требуемое сообщение. Это сообщение может включать название выполняющегося кода или значения любых переменных, которые Вы захотите получить в этой точке выполнения кода. Хотя строка сообщения может иметь длину до 200 символов, на реально отображаемую длину сообщения воздействуют такие факторы, как шрифт сообщения и ограничения менеджера окон времени выполнения (run time window manager). В реальной жизни, конечно лучше разбить длинное сообщение на несколько меньших. Убедитесь также, что свойство "Console Window" формы установлено на правильный размер окна; иначе сообщение не появится вообще. Чтобы гарантировать, что сообщение выведется на экран в требуемой точке кода, добавьте сразу после команды “MESSAGE” команду "SYNCHRONIZE".

Пример:

message('The table contains '||to_char(empcount)||' employees');
synchronize;
message('Runtotals = '||:control.runtotals);
--Runtotals могут принимать одно из двух
-- значений “YES” или “NO”
synchronize;
message('Beginning Runtotals program unit');
synchronize;

Вместо команды “SYNCHRONIZE”, вы можете использовать команду “PAUSE”, которая не только синхронизирует вывод на дисплей, но и приостанавливает программу, вынуждая пользователя нажать на какую-либо клавишу для ее продолжения. Этот вариант является предпочтительным, если вы хотите привлечь внимание к сообщению и к тому, что именно в этой точке форма выводит на дисплей.

Приведенный выше пример иллюстрирует тот факт, что встроенные команды “MESSAGE” выводят на дисплей сообщение в виде строки символов, так что вы должны конвертировать любые числовые значения или значения типа даты к символьному виду. Кроме того, значения переменных должны оставаться вне одиночных кавычек, и должны быть объединены со строкой при помощи оператора конкатенации (||).

Использование встроенной команды “MESSAGE” может вызывать проблемы для приложений, содержащих более одного окна. Как и в случае с приемом комментирования кода, вы должны не забыть удалить (или закомментировать) код сообщения, как только вы изолировали проблему, поскольку эти сообщения могут вводить пользователя в заблуждение. Кроме того, вы можете обнаружить, что использование встроенной команды “MESSAGE” приведет к исчезновению ошибки во время выполнения программы! Если это случилось, попробуйте использовать только встроенную команду “SYNCHRONIZE”, потому что это указывает, что проблема могла быть связана с недостатком синхронизации между выводом на дисплей и внутренним состоянием формы.

ИСПОЛЬЗОВАНИЕ ОПЦИИ ВРЕМЕНИ ВЫПОЛНЕНИЯ "DEBUG_MESSAGES=YES"

Третий быстрый модификационный прием заключается в добавлении к командной строке выполняемого модуля формы опции "debug_messages=yes". Это приведет к автоматическому отображению сообщений, информирующих нас о том, какой триггер выполняется в данный момент. Как только вы столкнетесь с ошибкой во время выполнения программы, станет известно, какой триггер был запущен последним, и можно продолжить отладку именно с этой точки. Любой, кто работал еще в эпоху SQL*FORMS 3.0, помнит, что это был задаваемый по умолчанию режим при выполнении формы в режиме отладки.

Чтобы использовать эту опцию из окна Form Builder, отметьте опцию "debug_messages" на вкладке runtime после выбора из меню Tools -> preferences. При выполнении из командной строки просто добавьте опцию "debug_messages=yes". Если вы для того, чтобы запустить вашу форму, используете иконку Windows, добавьте опцию к сокращенной команде (shortcut). Для платформы Windows это может выглядеть примерно так:

c:\orant\bin\ifrun60.exe module=myform userid=scott/tiger debug_messages=yes

Для Unix:

f60runm module=myform userid=scott/tiger debug_messages=yes

Главный недостаток этого приема заключается в том, что надо подтверждать сообщения по мере выполнения каждого триггера, что быстро вызывает раздражение. Хотя при этом видны все отработавшие триггеры, выполняемые программные блоки не отображаются, а также нет возможности показать значения переменных. Вывод этих сообщений может вызвать тот же эффект, что и прерывание хода выполнения программы, с чем мы встретились при разборе встроенной команды “MESSAGE”. Тем не менее, этот прием полезен в тех случаях, когда вы понятия не имеете, какой триггер вызывает проблему; ну, а как только сужена область поиска, более подходящими могут оказаться другие приемы.

ИСПОЛЬЗОВАНИЕ ВСТРОЕННОЙ КОМАНДЫ “BREAK”

При выполнении формы в режиме отладки, встроенная команда “BREAK” вызывает отладчик форм Forms Debugger. Эта команда может рассматриваться как быстрый модификационный прием диагностики форм, потому что для ее использования о Forms Debugger надо знать сравнительно немного.

В ситуациях, где полезна встроенная команда “MESSAGE”, для того, чтобы посмотреть любые переменные в некой точке кода, не определяя при этом строку сообщения, можно использовать встроенную команду “BREAK”. Когда форма доходит до строки, в которой записана команда прерывания (“BREAK”), на экране появляется окно отладчика, и даже очень немного зная об его инструментальных средствах, вы сможете развернуть узлы на навигационной панели отладчика, чтобы ознакомиться со значениями системных переменных, переменных формы, переменных программы и глобальных переменных. Затем, когда можно будет продолжить выполнение программы, достаточно только нажать иконку “GO” (значок с изображением молнии). Даже если это – все, что вы знаете об отладчике форм, вы найдете этот прием очень полезным. Но, раз уж вызван отладчик, можно при желании воспользоваться любой из других его функций.

Кроме того, что не требуется явно кодировать строку сообщения, чтобы отобразить нужные вам значения переменных, еще одно преимущество “BREAK” над командой “MESSAGE” состоит в том, что нет никакой необходимости удалять или комментировать строку с командой “BREAK”. Если форма выполняется не в отладочном режиме, “BREAK” не будет оказывать никакого влияния на выполнение программы, так что ваши потребители не будут и знать, что вы оставили команду в программе.

ДИАГНОСТИКА С ПОМОЩЬЮ FORMS DEBUGGER

Отладчик форм (Forms Debugger) – это простой интерфейс, который обеспечивает разработчику высокую степень контроля при отладке приложений. Вы не только можете просматривать значения переменных, но даже изменять их во время выполнения, чтобы исследовать, как различные их значения влияют на результаты. Вы можете двигаться по коду и даже, если хотите, изменять его на время сеанса отладчика. Для Forms 5.0 и более поздних версий вы можете отлаживать серверный код, просматривать значения в таблицах PL/SQL и знать, какую строку обрабатывает курсор.

Forms Debugger обеспечивает исчерпывающий набор инструментальных средств для отладки Oracle Forms, а его основные возможности весьма легки в использовании. Как только вы овладеете основными возможностями отладчика, вы, вероятно, если и не откажетесь совсем от быстрых модификационных методов, то станете использовать их только для наиболее элементарных задач.

Рисунок 1: Вызов отладчика из окна Form Builder

ВЫЗОВ FORMS DEBUGGER

Самый простой способ вызвать отладчик форм – это щелкнуть в окне Forms Builder по иконке отладки, которая появляется как в навигаторе объектов, так и в графическом редакторе (canvas layout editor). В Forms 6.0 при этом происходит выполнение формы в отладочном режиме. В более ранних версиях – это некоторый переключатель, который определяет, должна ли форма выполняться в режиме отладки, когда вы нажимаете иконку выполнения. Вы можете сделать то же самое для Forms 6.0, используя опции меню Tools Options или Preferences. Вы можете также выполнять Forms Debugger, определяя "debug=yes" в командной строке. Чтобы это сделать, вы должны вместо нормального исполнимого модуля формы использовать отладочный исполнимый модуль, и, к тому же, форма должна быть сгенерирована в отладочном режиме. Например, чтобы работать в режиме отладки на платформе Windows задайте:

c:\orant\bin\ifdbg60.exe module=myform userid=scott/tiger debug=yes

Третий метод вызова формы на выполнение в отладочном режиме состоит в том, чтобы взвести флажок “Run in Debug Mode” в окне выполнения. Если вы выполняете форму в отладочном режиме и обнаруживаете, что не видите программный код, это значит, что форма не сгенерирована для отладки. При выполнении формы в отладочном режиме из окна Form Builder она автоматически генерируется в отладочном режиме.

Если вы работаете с Forms 5.0 или более старшими версиями и не видите серверный код, следует повторно оттранслировать этот код на сервере, чтобы включить в него отладочную информацию:

ALTER PROCEDURE procname COMPILE DEBUG;

Такая повторная трансляция даст возможность пошагового выполнения серверного кода с использованием Forms Debugger и Forms 5.0 или более поздних версий. Если форма выполняется в отладочном режиме, окно отладчика будет выводиться на дисплей при первом появлении формы, а также всякий раз, когда при выполнении программы будут встречаться отладочные действия (об этом будет идти речь ниже). Вы можете также вручную вызвать окно отладчика во время выполнения формы в отладочном режиме, выбирая в меню Help -> Debug.

КОМПОНЕНТЫ FORMS DEBUGGER

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

Рисунок 2 – Компоненты Forms Debugger

РАЗДЕЛ ИНСТРУМЕНТАЛЬНОЙ ПАНЕЛИ/МЕНЮ

Доступные опции инструментальной панели и параметры меню изменяются в зависимости от того, что отображено в панелях окна. Пять кнопок слева на инструментальной панели управляют выполнением кода, в то время как красная кнопка X закрывает отладчик, а вопросительный знак выводит на дисплей справку. Остальные кнопки относятся к панели навигатора.

ПАНЕЛЬ ИСХОДНОГО ТЕКСТА

На верхней панели в режиме “только для чтения” отображается текущий блок программы, если таковой вообще имеется.

ПАНЕЛЬ НАВИГАТОРА

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

ПАНЕЛЬ ИНТЕРПРЕТАТОРА

Нижняя панель предназначена для ввода и отображения команд интерпретатора PL/SQL.

ИСПОЛЬЗОВАНИЕ ОТЛАДЧИКА

Наиболее общее применение отладчика состоит в том, что в определенной точке кода выполнение программы приостанавливается, что позволяет проанализировать ход выполнения, а затем продолжить движение по коду, чтобы увидеть, как каждая его строка воздействует на среду выполнения и форму. Кроме того, можно вводить команды непосредственно в интерпретатор PL/SQL, или изменять строки программы и значения переменных, чтобы видеть, как эти модификации воздействуют на выполняющуюся форму.

ПРИОСТАНОВКА ВЫПОЛНЕНИЯ ПРОГРАММЫ В ФОРМЕ

Выполнение программы приостанавливается, когда отладчик встречается с отладочными действиями. Имеются два типа отладочных действий: точки останова и триггеры отладки.

ТОЧКИ ОСТАНОВА

Точка останова сообщает форме, в каком месте следует приостановить выполнение кода и вызвать отладчик. Вы можете устанавливать точки останова только на выполнимых операторах. Если Вы попытаетесь установить точку останова на комментарии, операторе begin, объявлении переменной или другой невыполнимой строке программы, вы получите сообщение об ошибке. Имеются три пути установки точек останова:

1. ДВАЖДЫ ЩЕЛКНУТЬ ПО ЖЕЛАЕМОЙ СТРОКЕ ПРОГРАММЫ В ПАНЕЛИ ИСХОДНОГО ТЕКСТА: На панели навигатора выберите модуль, который вы выполняете, затем выделите триггер или программный блок, куда нужно вставить точку останова. В результате этот программный блок попадет на панель исходного текста (верхнюю панель). Чтобы вставить точку останова, дважды щелкните по номеру строки, перед которой желательно сделать паузу.

2. ВВЕСТИ КОМАНДУ В ИНТЕРПРЕТАТОР PL/SQL: Введите следующую команду в панели интерпретатора (нижняя панель):

.BREAK PROG LINE

Или же в панели исходного текста щелкните на желаемой строке, а затем введите в интерпретаторе следующую команду:

.BREAK

Но зачем Вам это нужно, если при двойном щелчке по номеру строки текста программы в панели исходного текста команда прерывания автоматически вводится для передачи в интерпретатор?

3. ИСПОЛЬЗОВАТЬ В ФОРМЕ ВСТРОЕННУЮ КОМАНДУ “BREAK”: Как обсуждалось в разделе "быстрые модификационные методы" – это единственный способ установить "стационарные" точки останова. Все установленные в сеансе отладчика точки останова исчезают, когда вы закрываете форму, и должны быть заново установлены при последующих выполнениях формы в отладочном режиме. Если вам нужно, чтобы программа прерывала свою работу каждый раз, когда запускается отладчик, внесите эту команду в форму. Помните, что встроенная команда “break” срабатывает только тогда, когда форма выполняется в отладочном режиме, так что она не помешает работе пользователей.

ТРИГГЕРЫ ОТЛАДКИ

Другой способ приостановить выполнение программы – использование триггеров отладки. Триггер отладки – это определенный Вами блок кода, который выполняется:

(a) каждый раз, когда управление передается отладчику,

(b) в каждой строке выполняемого исходного текста,

(c) когда встречается определенная строка исходного текста.

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

IF Debug.Getn('my_sal') > 5000 THEN

raise Debug.Break;

END IF;

В этом коде вызываются функции пакета DEBUG, который документирован в разделе интерактивной справки "О пакете DEBUG".

ИССЛЕДОВАНИЕ СРЕДЫ ВЫПОЛНЕНИЯ

После того, как Вы установили требующиеся отладочные действия, можно закрыть отладчик форм, щелкнув для этого по красной иконке со значком "X". Форма будет работать нормально, пока ее выполнение не дойдет до строки программы с установленной в ней точкой останова. Остановка произойдет до выполнения этой строки программы. В этой точке можно проанализировать среду выполнения, а именно:

значения элементов (включая неотображаемые элементы), параметры, глобальные переменные, системные переменные,

параметры командной строки,

программный стек (стек вызовов), наряду со значениями переменных программного блока для каждого уровня стека

ПОШАГОВОЕ ПРОДВИЖЕНИЕ ПО КОДУ

Вы можете использовать кнопки управления программой на инструментальной панели, чтобы выполнить код формы любым требующимся способом. При использовании Forms 5.0 и более старших версий с RDBMS версии 7.3.4 + или 8.0.4 +, имеется также возможность отлаживать блоки программы, которые хранятся в базе данных (серверная отладка).

Step into (Шаг внутрь): первая кнопка слева выполняет следующую строку программы. Это полезно, если вы хотите индивидуально выполнить каждую строку, чтобы узнать, как ее код воздействует на переменные формы и среды выполнения. При этом вы будете попадать и в вызываемые подпрограммы, что позволит выполнять также код подпрограмм.

Step over (Пропустить): следующая кнопка позволяет выполнять следующую строку программы, пропуская при этом вызываемые подпрограммы; другими словами, подпрограмма выполнится, но вам не придется проходить через каждую строку кода подпрограммы. Отладчик возобновит свою работу после выполнения подпрограммы.

Step out: (Выйти): третья кнопка управления после выполнения текущей подпрограммы возвращает управление отладчику, останавливаясь в том месте, где вызывалась подпрограмма. Используйте ее, если вы начали движение по подпрограмме, но затем решили, что ее пошаговое выполнение не требуется.

Go (Продолжить): при нажатии этой кнопки (GO) в обычном режиме (без пошагового выполнения команд) выполняется последующий код до завершения программы или до достижения другой точки останова. Используйте эту кнопку, чтобы убрать окно отладчика и возобновить (продолжить) нормальное выполнение формы.

Reset (Сброс): пятая и последняя кнопка управления программой прерывает выполнение блоков программы, которые выполняются в настоящее время, возвращая управление внешнему уровню отладки. Если в то время, как управление программой принадлежит отладчику, он сталкивается с несколькими точками останова, может иметься несколько различных уровней отладки.

При каждом шаге по коду Вы можете, если это необходимо, непосредственно вводить команды PL/SQL и исполнять проверку или модификацию значений переменных или кода.

ВВОД КОМАНД В ИНТЕРПРЕТАТОР PL/SQL

Если вы выполняете в отладчике действия ГИП (Графического Интерфейса Пользователя), то можете заметить, что команды повторяются на экране в панели интерпретатора PL/SQL. ПО желанию эти и другие команды можно ввести непосредственно. Ниже приведены примеры команд PL/SQL, которые могут быть введены с панели интерпретатора:

УСТАНОВИТЬ ТОЧКУ ОСТАНОВА

.BREAK PROG LINE

Обозначение PROG применяется вместо PROGRAMUNIT, но если вы предпочитаете, можно использовать более определенные термины PACKAGE, SUBPROGRAM, PROCEDURE или FUNCTION.

Вы можете также определить триггер, который будет выполняться при достижении точки останова.

ПРОСМОТР ИСХОДНОГО ТЕКСТА

.LIST PROG

СПИСОК ОПРЕДЕЛЕННЫХ В НАСТОЯЩЕЕ ВРЕМЯ ПРОГРАММНЫХ БЛОКОВ

.SHOW PROG

ЭКСПОРТ ПРОГРАММНЫХ БЛОКОВ В ФАЙЛ

.export prog * file C:\.pls

Эта функция полезна для документирования всего кода PL/SQL формы. Однако имеется один существенный недостаток: в файл не выводятся названия программных блоков. Поэтому, если вы намерены использовать эти функциональные возможности, нужно в начале каждого программного блока поместить комментарий, в который включено его название и уровень триггера. Например, в триггере when-button-pressed (если нажата кнопка), Вы могли бы поместить такой комментарий:

/* CONTROL.BUTTON1.WHEN-BUTTON-PRESSED trigger

*/

РАСПЕЧАТАТЬ ЗНАЧЕНИЯ ОБЩИХ (PUBLIC) ПЕРЕМЕННЫХ ПАКЕТА

TEXT_IO.PUT_LINE (< PACKAGE.VARIABLE >);

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

СОЗДАНИЕ МОДИФИКАЦИЙ ВО ВРЕМЯ ВЫПОЛНЕНИЯ

Во время отладки формы, можно увидеть результаты изменения кода. В окне Form Builder можно изменить код и повторно испытать его, но если всего лишь нужно проверить, как модификация кода воздействует на выполняющуюся форму, можно провести эти изменения в отладчике форм. Однако следует учесть, что эти модификации не сохранятся; они будут действительны только для текущего сеанса отладчика. Если требуется сохранить сделанные изменения, их можно скопировать в окне отладчика и вставить в программный блок в окне Form Builder, а затем сохранить код, чтобы сделать изменения постоянными. Подобным способом можно проверить, как различные изменения в значениях программных переменных будут влиять на результаты выполнения формы, в то время как форма выполняется в отладчике.

Модификация кода программы или значений переменных производится в панели навигатора. Чтобы вызвать на экран редактор PL/SQL, нужно дважды щелкнуть по иконке программного блока. Заметьте, что если этот программный блок находится в текущем стеке вызовов, он будет доступен в режиме “только для чтения”. В противном случае вы имеете возможность сделать модификации, которые будут действительны только на время сеанса отладчика. Вы можете изменять значения переменных программы в стеке вызовов панели навигатора, и даже изменять значения элементов форм, спускаясь вниз "модульном" узле навигатора. Для этого нужно всего лишь выбрать в навигаторе переменную, а затем выделить ее и изменить ее значение. Последующие строки программы, ссылающиеся на эту переменную, будут использовать ее новое значение.

ОГРАНИЧЕНИЯ ОТЛАДЧИКА

В отладочном режиме обработка ошибок функционирует по-другому. Триггеры on-error и on-message не срабатывают, а любые ошибки или сообщения отображаются как предупреждения. Это является усовершенствованием по сравнению с SQL*FORMS 3.0, где при выполнении формы в отладочном режиме вам советовали вручную временно отключить триггеры on-error и on-message.

Имеется много встроенных элементов, которые не будут выполняться до тех пор, пока форма не будет запущена на выполнение в отладочном режима. Их список находится в разделе интерактивной справки: "Об ограничениях запуска отладчика".

Не пробуйте вызывать из отладчика подсказку. Это вызывает ошибку PDE. См. сообщение об ошибках Forms номер 438135.

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

Как уже упоминалось, нет способа сохранить отладочные действия (точки останова и триггеры), созданные в отладчике. Их нужно повторно вводить в каждом сеансе отладчика, если только Вы не используете встроенную в ваш код команду “BREAK”. Кроме того, не существует никакого способа сохранить сделанные в программных блоках модификации.

ПРЕИМУЩЕСТВА ОТЛАДЧИКА ФОРМ

Несмотря на описанные ограничения, отладчик форм является полезным инструментом для получения детального представления большинства элементов среды формы во время исполнения. Это дает возможность создавать сценарии “what if” (“что, если…”), изменяя “на лету” код программы и значения переменных, и вы можете легко обнаруживать результаты выполнения каждой строки кода. Кроме того, при использовании пакетов типа OLE2 или TEXT_IO, вы получите более осмысленные сообщения об ошибках при выполнении в отладочном режиме, даже если не было установлено ни одной точки останова, а только пошаговое выполнение кода. Из-за функциональных возможностей и простоты использования отладчик форм является ценным пополнением вашего диагностического инструментария.

ДИАГНОСТИКА ПРИ ПОМОЩИ ЖУРНАЛИЗАЦИИ И ТРАССИРОВКИ

Имеются несколько методов, которые используют журнализацию и трассировку для создания отчетов о выполнении формы. Они полезны для детального анализа. Часто при анализе журнального файла можно обнаруживать кое-что, что было упущено при работе с отладчиком. Кроме того, если не удается самостоятельно решить проблему, можно послать журнальный файл аналитику службы поддержки Oracle (Oracle Support), чтобы он оказал техническую помощь.

Не упустите из виду электронную поддержку через MetaLink - постоянно (и, к тому же, бесплатно) доступный источник помощи, если у Вас имеется лицензия Oracle Support. Это дает доступ ко многим документам, которыми пользуются аналитики службы поддержки, чтобы помогать заказчикам решать их проблемы. Журнализация может дать информацию по кодам ошибок, сообщениям об ошибках, расположенных в стеке данных трассировки, и Java. Далее вы можете сделать по этим ключевым словам запрос в MetaLink, чтобы найти статьи, имеющие отношение к вашей конкретной проблеме. Зарегистрироваться для MetaLink можно по адресу http://metalink.oracle.com/.

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

DEBUG_SLFIND

На платформах, отличных от Windows, проблемы иногда могут возникать из-за несоответствующего использования файлов ресурса. Можно, например, обнаружить, что некоторые из клавишей работают не так, как вы ожидаете, или что внешний вид формы не такой, каким должен быть. Скорее всего, это происходит из-за того, что программа (Forms) не может найти пользовательский ресурс-файл или файл TK2MOTIF, и заменяет их на задаваемый по умолчанию ресурс-файл, в котором клавиши или визуальные аспекты формы определены по-другому. Или же вы при запуске формы получаете ошибки FRM. А для того, чтобы обнаружить проблемы с использованием ресурс-файла, следует использовать журнальный файл DEBUG_SLFIND, доступный на платформах Unix или VMS.

Этот журнальный файл инициализируется установкой переменной среды с последующим выполнением формы. Приведем пример синтаксиса для Unix:

> setenv DEBUG_SLFIND output.txt

> f60runm module=test userid=scott/tiger

> more output.txt

Полученный журнальный файл довольно просто интерпретировать. Он содержит все вызовы, с которыми Forms обращается в среду, указывает переменные среды, пути поиска файлов и разыскиваемые ресурс-файлы, а также файлы, к которым были обращения.

ТРАССИРОВКА SQL (SQL TRACE)

SQL Trace – это выполняющиеся на сервере операторы трассировки SQL. Они создают на сервере базы данных в каталоге, указанном параметром USER_DUMP_DEST в файла init.ora, файл трассировки. Основная цель трассировки – последующая настройка операторов SQL.

Трассировка может быть инициирована для всех подключений к базе данных, если в файле init.ora определен параметр SQL_TRACE=TRUE.

Однако обычно бывает намного полезнее трассировать каждый сеанс отдельно. Вы можете сделать это в Form Builder, отметив на экране поле "Statistics", где определяются опции времени выполнения, или в командной строке runform (выполнить форму) с параметром STATISTICS=YES.

Перед их интерпретацией файлы трассировки необходимо конвертировать в читаемую форму. Чтобы выполнить такое конвертирование, можно использовать команду TKPROF. В результате выполнения команды TKPROF создается файл, в котором перечисляются все операторы SQL, время выполнения каждого оператора (если в файле init.ora для базы данных установлено значение TRUE параметра TIMED_STATISTICS), и планы их выполнения (если в командной строке для TKPROF используется опция "explain=userid/password"). Приведем пример использования команды TKPROF для конвертирования файла трассировки SQL в читаемую форму:

Tkprof ora_8927.trc /tmp/tkprof_8927.txt explain=scott/tiger

Для платформы Windows команда изменяется в соответствии с версией базы данных (tkprof73, tkprof80) – название соответствующего выполнимого модуля можно найти в каталоге $ORACLE_HOME\bin.

ТРАССИРОВКА SQL*NET (SQL*NET TRACE)

Трассировка SQL*Net – это трассировка операторов SQL на клиентской стороне. При этом перехватывается каждое взаимодействие между любым клиентским инструментальным средством и любой версией базы данных, а Вам сообщаются изданные операторы SQL и возвращенные данные.

Вы можете инициировать трассировку SQL*NET, установив в файле sqlnet.ora на клиентской стороне два параметра настройки:

Set TRACE_LEVEL_CLIENT=16 (имеется 16 уровней трассировки; 16 – это наиболее детальный уровень).

Set TRACE_DIRECTORY_CLIENT указывает на каталог, в котором Вы хотите создать файл трассировки.

Необязательный параметр: Set TRACE_FILE_CLIENT задает используемое название файла трассировки (значение по умолчанию – sqlnet.trc).

Поскольку команда SQL*NET Trace создает очень большие файлы трассировки и может повлиять на эффективность работы, вы должны как можно скорее выйти из клиентского сеанса и отключить трассировку, снова изменив значение соответствующего параметра в файле sqlnet.ora:

TRACE_LEVEL_CLIENT=OFF

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

Если нет возможности изменить файл sqlnet.ora, потому что, скажем, он находится в общей сети, вы можете для среды Windows создать его локальную копию и установить переменную системного реестра TNS_ADMIN так, чтобы она указывала на локальный каталог, где находится этот файл. Для Unix Вы можете создать копию этого файла в основном каталоге и назвать ее ".SQLNET.ORA" (обратите внимание на точку, предшествующую имени файла). Этот файл будет использоваться вместо общедоступной копии.

Вы можете читать файлы трассировки непосредственно; однако, их может быть несколько затруднительно интерпретировать. В них будет, вероятно, содержаться много не представляющей для вас интереса информации, в то время как основной элемент файла, который, вероятно, будет Вас интересовать – это распечатка операторов SQL, генерируемых формой. К счастью, утилита TRCEVAL поможет Вам отобрать из файла трассировки полезную информацию:

Использование: trceval [-параметры] <имя файла>

Где -параметры могут принимать одно или несколько значений из следующего списка:
c – резюме информации о подключениях
d – детализированная информация о подключениях
f – формировать статистики сгенерированной трассировки приложения
s – полные статистики сгенерированной трассировки
t – детализированная информация пакета двух задач
u -- резюме информации пакета двух задач
q – для опции -u отображает завершенные команды SQL

Например, Вы можете использовать следующую команду, переназначающую выход утилиты TRCEVAL в файл, который называется "mytrace.txt":

Trceval -qu sqlnet.trc > mytrace.txt

Сравнение размеров файлов, получающихся после трассировки простой формы с последующим применением к нему утилиты TRCEVAL показало, что файл трассировки имеет размер 169Кб, а файл, сгенерированный TRCEVAL, – только 5Кб. Чтобы в некотором конкретном файле трассировки, который выглядит подобно приведенному ниже файлу, найти первый оператор SQL, выданный формой, вы должны просмотреть 3041 строку:

 
nspsend:00 CD 00 00 06 00 00 00 |........|
nspsend:00 00 03 47 0C 71 80 00 |...G.q..|
nspsend:00 02 00 00 00 C4 E5 91 |........|
nspsend:01 28 00 00 00 00 00 00 |.(......|
nspsend:00 00 00 00 00 B0 81 7A |.......z|
nspsend:02 07 00 00 00 3C 6E D7 |.....< |........| 00 nspsend:00 13 03 01 0D 0E 17 02 .......| | nspsend:20 DEPT| |ROM 54 50 45 44 20 4D 4F nspsend:52 F| |,ROWID 46 49 57 52 nspsend:2C |NAME,LOC| 43 4C 2C 41 nspsend:4E |DEPTNO,D| 4E nspsend:44 |.SELECT 53 |..n.....| 04 D7 6E 8C>

Однако, в файле, сгенерированном из этого файла трассировки командой TRCEVAL (с использованием опции -qu), оператор SQL появляется уже в 37-й строке и выглядит следующим образом:

SELECT DEPTNO,DNAME,LOC,ROWID FROM DEPT

TRCEVAL не показывает посланные и полученные данные, но вы можете, если это необходимо, обратиться к файлу трассировки. Таким образом, до тех пор, пока вам не требуется вся детальная информация по сетевым пакетам, утилита TRCEVAL – это то, что надо!

Операторы SQL в этом файле используют переменные связи. Например:

SELECT EMPNO,ENAME,JOB,MGR,HIREDATE,SAL,COMM,DEPTNO,ROWID FROM EMP WHERE (DEPTNO=:1)

Переменная связи (в этом примере ":1"), показывает, что этот оператор сгенерирован внутри Forms. Если бы это был оператор, написанный программистом, как это бывает в тех случаях, когда вы определяете явный курсор для выборки данных, переменная связи началась бы с "b", например, ":b1".

Трассировка SQLNet не только позволяет вам видеть операторы SQL, издаваемые Forms, тем самым, давая представление о том, что происходит за кулисами, но и может давать Вам все подробности относительно ошибок, произошедших на сервере, которые составляют стек. Ее (трассировки) полезность становится очевидной, если вы вспомните про цель приложения на Forms: обеспечить простой интерфейс пользователя для ввода операторов SQL DML (select, insert, delete, update) для базы данных.

СООБЩЕНИЯ ОБ ОШИБКАХ FORMS ВРЕМЕНИ ВЫПОЛНЕНИЯ

Начиная с Developer 1.6.1 (Forms 4.5.10.1.0), Developer 2.1 (Forms 5.0.6.5.1) и Developer 6.0 (все версии Forms), вы имеете возможность использовать сообщения об ошибках времени выполнения Forms (Forms Runtime Diagnostics – FRD). Это аналогично выполнению формы в отладочном режиме и распечатыванию всех происходящих событий. Хотя вы не сможете воздействовать на результат, изменяя значения переменных или команды программы “на лету”, тем не менее, вы получаете полный журнальный файл, содержащий следующие типы сведений:

Открытые файлы (fmx и mmx)

Каждый сработавший триггер вместе с уровнем срабатывания

Каждый встроенный выполнимый модуль (every built-in that executes), включая его параметры

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

Полный текст сообщений об ошибках форм и необработанных исключительных ситуациях

Каждый сделанный выбор из меню

У FRD имеются недостатки по сравнению с выполнением формы в отладочном режиме. FRD не позволяет вам пошагово двигаться по коду, и фактически даже не показывает, какие программные модули выполняются. Вы не способны видеть значения переменных программы или элементов Forms во время выполнения триггера, хотя вам доступны элементы формы, которые изменились после завершения выполнения триггера.

Выполнить форму с активизированной диагностикой совсем просто. Нужно только добавить к командной строке опцию "record=collect" (для формы, развертываемой в Web, эта опция добавляется к параметру serverArgs в файле HTML). По желанию вы можете специфицировать имя журнала, прибавляя к командной строке опцию “log=”. Примеры:

D:\ORANT\BIN\ifrun60.EXE module=testform userid=scott/tiger record=collect
log=frd.log
Netscape: serverArgs="module=testform userid=scott/tiger record=collect
log=frd.log"
Internet Explorer:

Вы можете комбинировать сообщения об ошибках времени выполнения с выполнением формы в отладочном режиме, совмещая тем самым “лучшее из обоих миров”:

D:\ORANT\BIN\ifdbg60.EXE module=testform userid=scott/tiger record=collect
log=frd.log
debug=yes

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

Не забудьте также, что если файл с тем же самым названием уже существует, FRD записывает поверх своего предыдущего журнала; нет способа добавлять информацию в конец журнального файла. Кроме того, журналы могут быть очень большими, так что используйте этот метод только для конкретных ситуаций. Если FRD неспособна писать в журнал из-за переполнения файловой системы или какой-либо другой проблемы, форма продолжит функционирование, но запись в журнал производиться не будет. Отладка с помощью FRD может быть особенно полезна, когда пользователь получает необъяснимые ошибки в Form, но неспособен даже точно объяснить вам, что это за ошибки. Активизируйте для такого пользователя FRD, и как только он сообщит, что проблема повторилась, исследуйте журнальный файл. Вы сможете точно определить, что делал в форме пользователь в момент возникновения ошибки.

НАСТРАИВАЕМАЯ ЖУРНАЛИЗАЦИЯ С ПОМОЩЬЮ TEXT_IO

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

Если вы захотите создать пакет для выполнения настраиваемой журнализации, то моделью для этого может послужить следующий пакет, описанный в документе Oracle Note:61692.1 FORMS DEBUGGING TECHNIQUES:

 
PACKAGE dbg IS
filename VARCHAR2(2000) := 'debug.out';
PROCEDURE output(
p_msg VARCHAR2
);
END;
PACKAGE BODY dbg IS
PROCEDURE output(
p_msg VARCHAR2
) IS
outf TEXT_IO.FILE_TYPE;
BEGIN
outf := TEXT_IO.FOPEN(filename, 'a');
TEXT_IO.PUT(outf, NAME_IN




 
 
 
 
 
 
 
 ('SYSTEM.CURRENT_DATETIME') || '-');
TEXT_IO.PUT_LINE(outf, p_msg);
TEXT_IO.FCLOSE(outf);
EXCEPTION
WHEN OTHERS THEN
IF TEXT_IO.IS_OPEN(outf) THEN
TEXT_IO.FCLOSE(outf);
END IF;
END;
END;

Вы можете передать в dbg.output строку, и эта строка будет добавлена в конец журнала вместе с меткой времени. Например:

dbg.output(‘The value of salary is ‘ || to_char(empsal));

Для его активизации необходимо, чтобы параметр формы передавал некоторое значение. Чтобы добиться этого, вы можете прибавить к форме вызываемый параметр, например, FORM_DEBUG, и исправить код в пакете dbg для обеспечения возможности условного выполнения:

if :PARAMETER.FORM_DEBUG=’YES’ then

-- Поместите эту строку в тело пакета после BEGIN

Теперь достаточно поместить перед строкой "EXCEPTION" оператор "end if", и вы получите условную журнализацию. При нормальных обстоятельствах не создается никакого журнала. Запись в журнальный файл будет вестись только в случае, если в командной строке или (для формы, выполняющейся в Web) в параметре serverArgs файла HTML будет передано значение параметра формы "FORM_DEBUG=YES":

D:\ORANT\BIN\ifrun60.EXE module=test_form userid=scott/tiger FORM_DEBUG=YES
Netscape: serverArgs="module=testform userid=scott/tiger FORM_DEBUG=YES"
Internet Explorer:

Этим путем вы можете, когда это необходимо, активизировать настраиваемую журнализацию и выводить любое требующееся вам сообщение. Возможности бесконечны!

ДИАГНОСТИКА ФОРМ, РАЗВЕРТЫВАЕМЫХ В WEB

Имеются несколько полезных приемов при разрешении проблем, с которыми сталкиваются при выполнении форм в Web. Ниже рассматриваются два таких приема, позволяющие получить более осмысленную информацию: журнализация информации о подключениях на Forms Server и выбор параметров для клиентской Java-консоли.

ЖУРНАЛИЗАЦИЯ ДЕЙСТВИЙ ПО ПОДКЛЮЧЕНИЮ

Чтобы получить информацию о подключениях к Forms Server, можно использовать средство Connection Activity Logging (журнализация действий по подключению), появившееся, начиная с Developer 1.6.0 (Forms 4.5.9.3.0), Developer 1.6.1, 2.1 и 6.0 (все версии). Оно активизируется при старте сервера Forms Server:

f60ctl ... log=log_file
f60svrm ... log=
ifsrv60 -listen log=

Чтобы активизировать журнализацию действий по подключению для платформы NT, нужно вручную запустить Forms Server из командной строки, или вручную же запустить службу с опцией log=. Вы не сможете активизировать ее, если при загрузке NT служба стартует автоматически.

Журнальный файл будет содержать все сообщения, порожденные Forms Server, включая:

сообщения при запуске Forms Server

запросы на подключение, обслуживание и разъединение

аварийные завершения

адреса IP, номера портов и обработку информации по идентификации процесса

Хорошая идея - сохранять службу Connection Activity Logging активизированной. Получающийся журнал относительно короток по сравнению с другими типами журнальных файлов, а содержащаяся в нем информация очень полезна для администраторов системы при диагностике проблем Forms Server. В более поздние версии Forms в журнальном файле включена трассировка стека действий по подключению в том случае, если имела место аварийная ситуация, что делает этот тип журнализации еще более ценным.

ПАНЕЛЬ УПРАВЛЕНИЯ JINITIATOR

Панель управления JInitiator имеет параметры, с помощью которых можно получать данные о формах, выполняющихся в Web. Для появления панели управления выполните следующие действия:

START -> Programs -> Oracle JInitiator Control Panel

Рисунок 3 – Панель управления Jinitiator

Убедитесь, что выбрана опция “Show Java Console”. После активизации на Java-консоли будут отображаться детализированные сообщения Java, поскольку приложение Forms выполняется в Web.

Вы также можете получить дополнительную информацию, нажав на вкладку "Advanced" и отметив окно "Enable Debug".

Начиная с JInitiator 1.1.7.15.1, появляется новая возможность: вы можете создать журнальный файл действий с кэшем файла JAR. Вы можете активизировать ее в поле “runtime parameter” панели управления Jinitiator, используя следующие опции:

Dcache.verbose=true выводит все операции с кэшем в окно консоли Jinitiator, включая попадания в кэш, справочник кэша, размер кэша, добавления к кэшу и удаления из кэша.

Dcache.verbose.hit=true выводит все случаи, когда выборка из файла происходит непосредственно из кэша.

Dcache.verbose.miss=true выводит случаи, когда требующуюся запись файла нельзя выбрать из кэша.

Dcache.logfile определяет журнальный файл, в который будет вестись дозапись в конец при каждом запуске Jinitiator.

Отсутствие установок означает, что журнализация не выполняется.

ВЫБОР ПОДХОДЯЩИХ ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ

Как теперь, когда вы знакомы со всеми этими методами диагностики, решить, какое из них является подходящим для конкретной ситуации? Имеется несколько общих рекомендаций:

быстрые модификационные – если форма относительно проста, а вам всего лишь требуется установить, где встречается проблема, может оказаться полезным один из быстрых модификационных методов: комментирование подозрительного кода, использование встроенной команды "message" или очень простой вызов отладчика Forms с использованием встроенной команды "break ". Если вы понятия не имеете, где источник проблемы, можно сначала использовать в командной строке опцию "debug_messages=yes", чтобы вывести сообщение для каждого сработавшего триггера; как только контекст сужен, можно использовать какую-либо другую методику для дальнейшего уточнения места нахождения проблемы.

Forms Debugger – Если вы во время выполнения формы должны контролировать или изменять среду времени выполнения, используйте Forms Debugger. Вы можете даже использовать его в комбинации с другими методами, например, некоторыми типами журнализации.

Журнализация/трассировка – если необходимо фиксировать поведение Forms во время выполнения формы, используйте один из методов журнализации или трассировки. Эти методы особенно полезны для сложных ситуаций, где может оказаться выгодной способность анализировать файл. Журнал должен предоставлять детальную информацию об ошибках, содержащую ключевые слова для запроса в MetaLink. Кроме того, аналитик службы поддержки Oracle сможет быстрее решить вашу проблему, если вы предоставите журнальный файл, в котором содержится регистрация действий формы.

Эти инструментальные средства должны стать прочным фундаментом вашего превращения в опытного диагноста Forms!

ССЫЛКИ

Большинство из этих ссылок были использованы при подготовке этой статьи; однако сюда же включены и другие, которые также могут оказаться полезными вам.

FORMS DEBUGGER

· Chapter 21, Oracle Developer/2000 Forms 4.5 Developer’s Guide Manual

· Chapters 2 and 5, Oracle Developer/2000 Procedure Builder 1.5 Developer’s Guide Manual

· Note:39322.1 GETTING STARTED WITH THE ORACLE FORMS 4.5 DEBUGGER

· Note:30941.1 Forms 4.5 Debugger Tutorial

DEBUG_SLFIND

· PR:1011276.6 DEBUG_SLFIND: HOW TO DEBUG CDE TOOLS PROBLEMS WITH RESOURCE FILES

SQL TRACE

· Appendix B of the ORACLE7 Server Application Developer's Guide (V7)

· Pr:1011728.6 SQL TRACING: HOW TO DEBUG CDE TOOLS PROBLEMS

· BUL 101128.035 QUERY AND APPLICATION TUNING USING EXPLAIN AND TKPROF UTILITY

SQL*NET TRACE

· PR:1012290.6 SQL*NET TRACING: HOW TO DEBUG CDE TOOLS PROBLEMS

· Note:34022.1 SQLNet Version 2 Tracing for Client Tools

FORMS UNTIME DIAGNOSTICS CONNECTION ALLOCTIVITY LOGGING:

· Note:62664.1 FORMS SERVER AND FORMS RUNTIME LOGGING by Duncan Mills

· Technical White Paper: Developer Forms Server Frequently Asked Questions, April 1999

TEXT_IO FOR CUSTOMIZED LOGGING

· Note:61692.1 FORMS DEBUGGING TECHNIQUES

METALINK

· PR:1016352.4 ORACLEMETALINK: ORACLE'S PREMIER WEB SUPPORT SERVICE -REGISTRATION AND FEATURES DEVELOPERSERVER

· Developer Server Troubleshooting Tips - available on Oracle Technology Network

http://technet.oracle.com/product/tools/dev2k/info/developertips.pdf