Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Programming PL SQL.doc
Скачиваний:
3
Добавлен:
01.07.2025
Размер:
5 Мб
Скачать
☆

20.5.3.1 Client pl/sql libraries at design time

The usual convention of designing client PL/SQL is to put only module-specific code into the application module, and to put anything used by more than one module into a library.

When you put code into a library, you must "attach" the library to the module to be able to use its programs. This simple task is accomplished with the object navigator in the design-time tools. The PL/SQL library file and the application module file (for example, .FMB) do remain separate, though, and you must remember to copy them both when distributing your code.

One of the aspects of using libraries that confuses beginners is the prompt asking whether to remove path information from the library. Oracle wants to know which of two alternatives you intend to use at runtime:

  • Retain full path information (such as c:\apps\forms\libs) because you will be deploying the library in exactly the same path in which you're developing it

  • Remove path information and have the application tool search for the library according to certain system variables

The first option may be more expedient during development, but the second is more flexible and probably better in the long run, even though it requires the extra step of setting the path variables. The runtime search order is this:

  1. First, check the tool-specific variable, such as FORMS90_PATH, REPORTS90_PATH, or GRAPHICS60_PATH.

  2. Then, if the variable is not found, look in ORACLE_PATH.

On Windows environments, you can set these variables either via the control panel ("System Properties") or in the registry. Apparently, you cannot simply define them in a batch file.

To reveal a bit more of the story, the Oracle client tools I have tested seem to resolve external program references using the following search sequence:

  1. Client-side built-in programs

  2. "Program units" defined in the module itself (.FMB)

  3. PLX versions of attached PL/SQL libraries on the path supplied by the environment variables discussed earlier

  4. If no PLX version, the PLL versions of the attached PL/SQL libraries

  5. Database server (using standard server name resolution)

When you are factoring programs into their best location during development, you will want to load both the PL/SQL library and an attaching application module (form, report, etc.) into the development environment at the same time. You will want to be conscious of saving a modified library before attempting to use any new features in the attaching module.

When modifying a library and an attaching module during the same editing session, you will need to do one or two things before the attaching module can see the changes. If you are using only the PLL version at runtime, you will need to save the PL/SQL library (File Save). If you have also generated a PLX version of the library on the path, you will need to generate it (File Administration Compile File, or Program Compile).

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]