The file NETBASE.INI must be in the Windows directory. The major entries in this file are listed below.
| [FILES] | This section has two variables, NBTROOT and DEFAULT, which specify where template files are found and which template file is called as the parent to all others. |
| NBTROOT=C:\reach\nbt\ | NBTROOT specifies the directory under which all RES-Reach template files are located. Only the account under which the RES-Reach service is running needs read access to these files. They should not be directly accessible from the Web Server. The Web server and the database engine may, of course, have access to other directories. |
| DEFAULT=default.nbt |
This is the name of the default template file; it must be in the directory
subtree specified in NBTROOT. As RES-Reach is asked
to process a template file, it calls this default file first, passing all
parameters to it. Generally, this template
A sample default.nbt is given as Example 3 in section 4.3 below. |
| [VARIABLES] | This is the list of "profile" variables available to the RES-Reach template (.NBT) files. You may add and modify profile variables as you wish. See Section 4.1 for more information on "profile" variables. |
| UNKNOWN=??? | This redefines the string returned for variables and fields that have not been assigned a value. |
| CALL_NBT={SCRIPT_NAME} METHOD=POST GET_NBT={SCRIPT_NAME} METHOD=GET |
These are examples of a recursive variable (see section 4.1). {SCRIPT_NAME} is
replaced by the contents of the appropriate HTTP variable at run-time.
You should use these variables in forms and anchors instead of a hard-coded RES-Reach URL. Then, as you move your application from the staging area or development server to the production environment, you only need to adjust this declaration. Your template files will not have to be revised. |
| DB=C:\REACH\DB | Can be used as a variable in NBT files.
The directory name of the database where queries will be made.
The syntax varies according to the database type.
This variable allows you to move the database directory after your RES-Reach templates have been written. |
|
CHECKED:-1=CHECKED CHECKED:-0= SELECTED:-1=SELECTED SELECTED:-0=
|
This set of variables allows you to use syntax like:
<DATA SQL="SELECT VAL='1' AS Val1...>
<RECORD>
<INPUT TYPE="CHECKBOX" {CHECKED:-{Val1}} NAME="Val" VALUE="1">
<SELECT NAME="Cars" SIZE="1">
<OPTION {SELECTED:-{Val1}} VALUE="1">FORD
|
|
[ERROR] MEMORY=MEMERR.HTM FILE=FILERR.HTM PARSE= IO=IOERR.HTM |
This section determines the files to be placed in the data stream to the browser in the event of each class of error. No parsing or processing is done on these files. If these files are absent, RES-Reach will use its internal default error processing. In the case of a parsing error, the default processing will display a code fragment near where the error occurred. While this is useful for debugging, it is not a good idea for accessible systems. |
| DATA=DATAERR.HTM | The default HTML error file to be processed if an SQL error is encountered. No RES-Reach parsing is done on the file. If blank, then local error processing is assumed. |
|
[DATA] ERROR=DATAERR.NBT |
In the case of a database error, it is possible to override default processing
with an NBT template file where parsing and execution can take place. It is
possible, for instance, to use RES-Reach DATA tags to record the error in a log.
Because of the possibility of a database error while logging, it is essential that
the RES-Reach DATA tag have an "ERROR" element that does no parsing or processing, in order
to avoid an endless loop (see section 4.4).
If this entry exists, then the "[ERROR]" section of NETBASE.INI should not include a "DATA" entry. |