flak@slovax.UUCP (06/17/87)
As promised, here's a list of undocumented features and bugs
for Informix. If you have anything to add or comments to make
about the list, please feel free to do so.
---------------cut here for "man" page---------------
FEATURES AND BUGS IN INFORMIX
1. Conventions.
a. The schema source file will be referred to as "filename.s",
(e.g., the file foo.s will produce foo.dat, foo.idx, and on
some systems, foo.lok).
b. Ace report source files will be referred to as "filename.a",
(e.g. foo.a will produce foo.a.arc).
c. Perform source files will be referred to as "filename.f",
(e.g. foo.f will produce foo.f.frm).
d. Files produced by dbstatus (or informer) download will be
referred to as "filename.dlf", (e.g. downloading database
file "foo" will produce a file called "foo.dlf").
2. Bugs:
a. On systems using an ".lok" file, the lock is not always
reset when a program using the file crashes.
b. Perform pictures. Any picture clause in a perform screen
will limit editing to overtype only. The CTRL-A, CTRL-X and
CTRL-D editing commands will not work.
c. There are incompatabilites between acego and aceprep, and I
suspect, between formbuild and perform when exchanging
".arc" files and ".frm" files across systems (I.e. WICAT to
HP or vice versa). even for the same version of Informix.
The ACE report or PERFORM screen must be recompiled. (You
*can* hack the source, if you've got it).
3. Undocumented Features
a. Feature: Restoration of a corrupted database.
(1) Procedure: If a corruption of the "idx" file occurs,
you may not be able to access all records. The follow-
ing technique is worth a try. Copy the "dat" file to a
temporary file. Using dbstatus, delete the old file.
Rebuild the file from sources. Using dbbuild, load the
database from the temporary file.
(2) Example:
June 16, 1987
- 2 -
cp foo.dat foo.dlf
dbstatus dbname
erase file foo
dbbuild foo.s
dbstaus dbname
load foo from "foo.dlf"
(3) Cautions and bugs: This procedure has always worked on
the few occasions I've had to use it.
b. Feature: dbstatus can accept commands from a "script" file.
(1) Procedure: Redirect commands from a script file. Where
a return is required, use CRTL-M. Since this mode is
not interactive, you'll have to anticipate the
responses to dbstatus requests. Make sure you ter-
minate the script with a "bye" statement.
(2) Example:
dbstatus dbname < script
where "script" contains something like:
erase file foo
y
load ascii bar from "bar.dlf"
bye
(3) Cautions and Bugs: Not terminating the file with a
"bye" statement will leave you in dbstatus with no way
out except to kill the process.
c. Feature: dbbuild can accept script files. This comes in
handy in makefiles when modifying existing database files.
(1) Procedure: Redirect commands from a script file. Where
a return is required, use CRTL-M. Since this mode is
not interactive, you'll have to anticipate the
responses to dbbuild requests.
(2) Example:
June 16, 1987
- 3 -
dbbuild -r foo.s < script
where script looks something like:
^My^M
(3) Cautions and Bugs: The above script works very well if
the list of changes takes only one page. Since the
number of data elements changed in a schema can vary,
anticipation of how many carriage returns are required
is difficult.
d. Feature: Inter System download / upload
(1) Procedure. For database files that are "pure" ascii (no
numeric data), you can "short cut" the dbstatus unload
function. Copy the ".dat" file to a temporary file.
Transfer the temporary file to another system. Use
dbstatus load to upload it. I have used this procedure
between WICATs, Vaxen, and HP's.
(2) Example:
cp foo.dat foo.dlf
uucp foo.dlf boo\!~uucp
(login to boo)
cp ~uucp/foo.dlf dbdirectory
dbstatus
load foo from "foo.dlf"
(3) Cautions and Bugs: The procedure is untested for file
"transfer" between systems of different types for non-
ascii files. I doubt that even dbstatus (plain) unload
will work. I suggest that when loading and unloading
data across systems, the dbstatus "ascii unload"
feature be used.
e. Feature: ".dat", ".idx", and ".lok" transfers.
(1) Procedure: It is not necessary to unload and reload
files on the same system. Copy the ".dat", ".idx" and
".lok" (depending on type locking used) to the desired
directory. If structures have been changed, copy the
updated "dbd" file as well.
(2) Example:
June 16, 1987
- 4 -
Directory 1 Directory 2
(Development) (User)
dbase1.dbd dbase2.dbd
foo.dat foo.dat
foo.idx foo.idx
foo.lok foo.lok
You've just made a change in directory 1, the database
schemas are the same except for file, foo. The file foo
already has all the data you want (if not download foo
in directory 2). All you have to do is:
cp directory1/foo* directory2
cp directory1/dbase1.dbd directory2/dbase2.dbd
Note the implication of the second copy command. If you
have several tables of the same format (but different
values contained within) for different applications you
can copy data "across" databases. The following exam-
ple assumes no changes in database structure. For
example, you may have a lookup table whose contents
differ for different users:
Directory 1 Directory 2 Directory 3
(Development) (User 1) (User 2)
dbase.dbd dbase.dbd dbase.dbd
user1.dat lookup.dat lookup.dat
user1.idx lookup.idx lookup.idx
user1.lok lookup.lok lookup.lok
user2.dat
user2.idx
user2.lok
cp directory1/user1.dat directory2/lookup.dat
cp directory1/user1.idx directory2/lookup.idx
cp directory1/user1.lok directory2/lookup.lok
cp directory1/user2.dat directory3/lookup.dat
cp directory1/user2.idx directory3/lookup.idx
cp directory1/user2.lok directory3/lookup.lok
(3) Cautions and Bugs: This procedure has actually worked
across systems with the same version of UNIX and byte
ordering. (I.e. between an HP 320, SYS V and WICAT SYS
V). Personally, I call that "pushing it".
h. Feature: Unlocking ".lok" files
(1) Procedure. Create a null ".lok" file.
June 16, 1987
- 5 -
(2) Example:
cat /dev/null > foo.lok
(3) Cautions and Bugs: This isn't the same lock file that
Informix creates for an unlocked file, but it does give
you access to the file. The normal Informix lock will
return when you first use the file.
June 16, 1987
--
{psivax,ism780}!logico!slovax!flak : {hplsla,uw-beaver}!tikal!slovax!flak
Dan Flak-R & D Associates,3625 Perkins Lane SW,Tacoma,Wa 98466,206-581-1322