Options in database applications

Most ODABA applications are referring to a configuration or ini-file in order to load actual option values. Besides, ODABA provides a standard option dialog, which allows storing user specific options in the application database. Finally, options might be set in the system environment or within the application while running the program.

Options are considered as thread global variables, i.e. each thread running in an application has got its own set of options. This allows changing option values in one thread without affecting other threads. When running in a client/server environment, each client may set options on the server side. Server options are also thread global and are stored separately for each client.

Options are supported in many places in the database system in order to increase flexibility of applications and programs. Thus, you may refer to options in

• file paths
• OSI expressions
• application programs

and in many other places. You may create your own options in your application or refer to options defined in ODABA.

Option values are searched in the following hierarchical order.

• First the options set internally by the application are checked.
• When not being found, the option is searched in the configuration or ini-file associated with the application. When being found, the option is copied to internal options.
• When still not being found, the option is searched for in the set of system environment variables. When being found, the option is moved to the set of internal options.

Option values not yet defined are created automatically and set to "". Thus, each option does exist by definition and returns a value, which might be empty.

Option set in the application database (e.g. by means of the options standard dialog) can be read into internal options by calling the Database ::initializeOptions() function or when running a GUI application by calling the ProjectContext ::initializeOptions() function. In a GUI application, user options are read from the database by default using the user's login name as configuration name.

Database paths but also most file path to external files opened in an ODABA application (e.g. locations for import or export) may contain option references ( %option_name% ). Those references are resolved before opening the file. A file path may contain any number of option references.

When the file is opened on the server, options must have been defined on the server side.

OSI expressions may refer to option variables. You may get but also set option values in an expression. Within an expression, you may refer to option variables as to normal expression variables, except, that they must be enclosed in %...%.

Referring to undefined option variables returns an empty string.

Options in expressions are typically used in order to define variable or generic expressions, which depend from one or more variables set at runtime.

In an application, one may retrieve option values by calling option() . In order to set or change an option value, Option:: assign() or the assignment operator ( = ) might be called.