When DB applications read database files, they must be able to
find them in various directories that may vary from system to system.
The DB library refers to a character string that consists of an ordered
list of directories to be searched for input files. This string
is called the database path, or the DB path. Under UNIX and
VMS, the DB path is a colon-separated list of prefixes, in the format
used for the Bourne shell's PATH variable. Under MS-DOS and on
the Macintosh, the DB path is in the format used for the MS-DOS
PATH variable, with semicolons used to separate prefixes (colons
retain their customary meanings, as drive letter suffixes under MS-DOS,
or as directory separators on the Macintosh). When a DB file must be
opened for input, the DB library attempts to locate it by attaching each
of the components of the DB path (one at a time) as a prefix to the file
name. If two or more matching files exist in different directories in
the DB path, the DB library opens only the file that resides in the
first of these directories named in the DB path. Any other matching
files are effectively invisible to DB applications unless the DB path is
rearranged.
When DB applications write database files, these files are generally written to the current directory. (As an example, an application that analyzes one or more signals in a record may record its findings in an annotation file in the current directory.)
Note particularly that the current directory is not necessarily part of the DB path. In order to be sure that your DB applications can read any DB files that you have previously written in the current directory, be sure that your DB path includes an empty (null) component, which corresponds to the current directory. In most cases, this null component should be the first in the DB path. Thus, if you write into the current directory a modified version of an existing DB file, any later actions that would read this file will read your modified version rather than the original.
A default DB path may be specified at the time the DB library is
compiled, by defining a value for the symbol DEFDBP in
`dblib.h'. On most systems, the environment variable DB, if
set, specifies the value of the DB path, and overrides the default value
if any. On the Macintosh, for which the concept of environment
variables is foreign, the DB path may be set only by using
DEFDBP.
If the DB library finds that the value assigned to the DB path is of the
form `@file', it replaces that value with the contents of
the specified file. (This feature was first introduced in DB
library version 8.0.) Indirect DB path files may be nested up to ten
levels (this arbitrary limit is imposed to avoid infinite recursion if
the contents of the indirect file are incorrect). This method of
indirect assignment is useful on the Macintosh, where recompilation of
the DB library would otherwise be necessary in order to change the DB
path. It may also be useful under MS-DOS to reduce the need for
environment space, or if the length of the command needed to set the
DB environment variable would otherwise approach or exceed the
128-byte limit for MS-DOS commands.
If a DB header file (see section Database Files) specifies that a signal file is to be found in a directory that is not already in the DB path, that directory is appended to the end of the DB path; in this case, if the DB path is not set, it is created with an initial null component followed by the directory that contains the signal file. (This feature was first introduced in DB library version 6.2.)
The string `%r' is replaced by the current record name wherever it appears in the DB path; `%Nr' is replaced by the first N digits of the record name, if N is a non-zero digit. For example, if (under UNIX) the DB path is `:/cdrom/mimicdb/%3r:/cdrom/mitdb', a request to read a file associated with record 055n will cause the DB library to look first in the current directory (since the DB path begins with an empty component), then in `/cdrom/mimicdb/055', and then in `/cdrom/mitdb'. If `%' is followed by any character other than `r' or a non-zero digit followed by `r'), that character is used as is in the DB path; thus a literal `%' can be included in the DB path by `escaping' it as `%%'. (Substitutions of `%'-strings in the DB path were first introduced in DB library version 9.7.)
Before the example program can be run successfully, DB must be
set appropriately and placed in the environment where it can be examined
by the running program. If you use the Bourne shell (sh), the
GNU Bourne Again shell (bash), or the Korn shell (ksh), do
so by typing
. setdb
(or by placing this command in your `.profile', which will cause
DB to be set automatically whenever you log in). If you use the
C-shell (csh) or a variant of it (such as ecsh or tcsh),
type
source /usr/local/bin/cshsetdb
(or put this command in your `.cshrc'). These shell scripts should
be available on any system on which the DB library itself is available,
although they may not be in `/usr/local/bin' as shown above. If
you cannot find the script you need, consult an expert (such as the
person who installed the DB library on your system). Note that the
default value for DB obtained in this way begins with the current
directory, and includes all standard directories in which database
records are kept. Thus, if you create your own database records or
files, you may keep them in your own directory without special
arrangements.
Under MS-DOS, you may set DB using the batch file
`dossetdb.bat' (created during installation of the DB Software
Package), or you may include the contents of that file in your
`autoexec.bat' file, which will cause DB to be set automatically
whenever your system is rebooted. Since environment space under
MS-DOS is an operating system resource and is often in very short
supply, you may need to allocate additional environment space within
your `config.sys' file, with a line of the form
shell=c:\command.com /p /e:512
See your MS-DOS manual for further information.
These shell scripts usually set the DBCAL environment variable,
which is important if you make use of records that contain signals other
than ECGs. DBCAL names a calibration file located in one
of the directories named by DB. (Beginning with DB library
version 8.3, the symbol DEFDBC may be defined in `dblib.h'
to specify the name of a default calibration file, to be used by the DB
library if DBCAL has not been set.) Each signal type may be
represented by an entry in the calibration file. Entries specify the
characteristics of any calibration pulses that may be present, and
customary scales for plotting the signals.
Go to the first, previous, next, last section, table of contents.