home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Frozen Fish 1: Amiga
/
FrozenFish-Apr94.iso
/
bbs
/
alib
/
d5xx
/
d593
/
analyrim.lha
/
AnalyRim
/
DBMSdocs.zoo
/
riminterface.doc
< prev
next >
Wrap
Text File
|
1992-01-05
|
9KB
|
212 lines
The AnalytiCalc RIM interface is a command interface to AnalytiCalc which
allows the AnalytiCalc user to operate on predefined RIM database
schemas. In the following let us assume the following RIM schema
definition is in effect:
DEFINE FOO
OWNER GCE
ATTRIBUTES
LABEL INT KEY
VAL DOUB
FRM TEXT VAR
RELATIONS
SS WITH LABEL VAL FRM
END
This defines a database containing one relation; each row of the relation
contains an index, a value, and a formula and the relation SS relates
these; each row contains one of each. The AnalytiCalc interface does not
understand all possible RIM datatypes due to the difficulty of presenting
some of them in a spreadsheet context. It does understand the following
types:
1. Integer (4 bytes)
2. Real (4 bytes)
3. Double (8 bytes) (NOTE: this is only partly functional!)
4. Text, variable length.
The AnalytiCalc commands that operate on RIM data all begin with CMD
and must be done in certain combinations. To allow the spreadsheet to
know the types of different RIM attributes, it is necessary to keep
a "title row" on the sheet. This contains the attribute names in a
format usable for titles, plus encoded type information.
The interface commands are as follows:
CMDOPEN dbname
Opens the RIM database named "dbname". (RIM code assumes the
database files are in the current default directory.)
CMDUSER password
Sets the current password (or "user") to "password". This is used
to match against owner, read, or modify passwords that may be set
on RIM relations.
CMDCLOSE
Closes the currently active database.
CMDGETATT relname,startcell:endcell
This command loads the "title row" from the relation "relname"
(which would be SS in the given example) into the spreadsheet starting
at startcell and working right from there. The endcell is used to
determine how many of the attributes to set (at most; if there are
fewer attributes in the relation, only those that exist are stored)
and does NOT determine direction. Rather the title row is ALWAYS a row.
CMDFIND relname
This command establishes a set of rows which can be pulled
into AnalytiCalc (via CMDGET) or loaded into (via CMDLOAD or CMDPUT)
storing them internally. The set and order of rows to be retrieved
may be altered AFTER a CMDFIND call by a CMDWHERE call or a
CMDSORT call. However, before any data can be accessed, a CMDGETATT
must have been done to store properties and CMDFIND, optionally
followed by CMDWHERE and/or CMDSORT, must be given.
CMDWHERE
CMDWHERE gives a single WHERE clause to qualify the rows
selected. The command format is
CMDWHERE attcell:valuecell,oper
so that the attribute name must be stored in attcell's formula
and the value must be in the value of the cell valuecell if
the attribute is numeric, or in the formula if it is text.
For example, the command
CMDWHERE C2:G5,GT
might express the qualifier
WHERE VAL GT 5.0
if cell G5 contained value 5.0 and cell C2 were the title cell for
attribute VAL in the example relation SS. Title cells may be used
or the cell may be any whose formula contains the attribute name
(space padded to 8 characters).
Unlike the situation in full interactive RIM, and owing
to the complexities of decoding, only a single qualifier is supported
in WHERE statements at this point.
CMDSORT
CMDSORT allows sorting of selected rows on one or more
keys prior to retrieval. The command format is:
CMDSORT attcell:typcell
The attcell formula must contain attribute names, space padded
And 8 characters apart (though if a title cell is used for a single
attribute, that is OK) to be sorted on. The formula of typcell contains
up to 6 characters, A or D, corresponding to up to 6 attribute names
(column names) in typcell. If an A is found in typcell, the attribute
is sorted in Ascending order. If a D is found, it is sorted in Descending
order. Up to 6 columns may be sorted on with one call.
CMDGET
CMDGET loads rows into a spreadsheet area that have been
readied by CMDFIND and possible CMDWHERE and CMDSORT commands.
The command format is:
CMDGET titlecell,ulcell:rlcell
where titlecell is the upper left end of the "title cell row"
loaded with CMDGETATT earlier for the relation. ulcell:lrcell
is an area on the spreadsheet in upper-left:lower-right format
to be filled in. The number of rows in this area controls the
number of rows that CMDGET will try to retrieve from the RIM
database, and the number of columns controls the number of
attributes of each relation to be stored in the spreadsheet. These
always start from the first attribute of each row of the relation;
there is no provision for skipping any.
CMDDEL
CMDDEL deletes rows from a RIM relation. It presumes you
have used CMDFIND, CMDWHERE, CMDSORT, and CMDGET to "position"
yourself in the RIM relation where you want to be, and then deletes
the N rows you tell it.
The command format is:
CMDDEL var
where var is a cell whose value is the number of rows of
the relation to delete.
CMDPUT
CMDLOD
CMDPUT and CMDLOD enter rows in a RIM relation. The command
format is
CMDPUT titlecell,valuerowcello:valuerowcellhi
or
CMDLOD titlecell,valuerowcello:valuerowcellhi
If using CMDPUT, you need to use CMDFIND etc. and CMDGET
to "position" yourself in the RIM relation where you want. CMDPUT
will then overwrite the relation at the last gotten cell with
data from the spreadsheet. By specifying an area, multiple
relation rows can be replaced with one call. One would use such
a thing by using CMDFIND et. al. and CMDGET to get data out
of a RIM relation, modify it on the sheet, then use CMDFIND
et. al. and possibly a shorter CMDGET (if the first several
relations were not to be changed) followed by CMDPUT to
replace some of the data.
The CMDLOD command just adds rows to the relation at the
end, so it does not require "positioning" oneself.
CMDRIM
CMDRIM
The CMDRIM command simply places you into RIM command mode,
from which point any RIM command is legal. This permits one to
access any and all RIM functions from AnalytiCalc. Should
AnalytiCalc input be coming from a command file, the RIM input
will do so also. An additional RIM keyword RETURN is added
and causes RIM to return to AnalytiCalc without closing its
data bases. The reason for this is to permit the other commands
to be used to find data and allow RIM WHERE clauses to be entered
in full generality prior to using CMDGET or CMDPUT. This avoids
the limitation of the rest of the AnalytiCalc RIM frontend
which permits only a single WHERE clause. Should automation
be desired, a command file driving both AnalytiCalc and RIM
components can be used.
CMDIRIM
CMDIRIM Rim-command
CMDIRIM will pass any RIM command to the RIM database component
of AnalyRim as a single line command. Then it will pass a RETURN
command to RIM so that the effect is to execute one line of command
followed by a return to the spreadsheet control sequence. This can
be used as a more convenient means to pass commands, via the
*U XQTCMD function from within cells or via interactive commands,
to the database. Where a single WHERE or SORT qualifier is desired,
this makes it simpler to use the normal RIM SQL-like syntax.
CMDSAV
CMDSAV locell:hicell
CMDSAV presets AnalytiCalc to capture RIM output (during
CMDRIM or CMDIRIM mode) into the given rectangular range of
cells. These cells will be filled in with the text of RIM
output verbatim (up to 109 characters each), one line of
output per cell. RIM output beyond 109 characters is not
saved (except in the -arg input array, for the last typed
command only). A CMDSAV command without the cell range arguments
turns off this output saving. Cells in the range that are filled
in become text cells (resettable as usual with DF commands if
such is needed.)
CMDKLON and CMDKLOF
RIM does not really store double precision data correctly,
so it is not fully functional. What RIM normally does is store a
single precision real in 8 bytes. AnalytiCalc stores true 8
bit double precision, on the other hand. When RIM is passed
this 8 bit data, it stores and retrieves it OK. At least on
the Sun architecture, however, it may compute incorrectly with
it. If such data is stored/retrieved by AnalytiCalc using CMDGET
and CMDLOD/CMDPUT and friends (but not via CMDRIM/CMDIRIM),
it will be handled consistently. Attempts to use the data across
the two interfaces will however not work well.
To allow the CMDGET routine to at least load RIM-stored
DOUB data (loaded via the CMDRIM interface), give the CMDKLON
command, which allows such data to be recognized and loaded by
converting to true real*8. To return to the totally consistent
model, give the CMDKLOF command (kludge on and off). The conversion
will only be done if the second half of the purported real*8
number is exactly zero, but this can happen legally for many
cases, making yet another command necessary.
The best course is to avoid using the DOUB type where
feasible, but this allows it to be used where it makes sense
to do so, provided one is willing to use the AnalytiCalc
command interface for all data accesses and examinations.
Note that the use of the RIM interface for adding
WHERE or SORT clauses should be harmless, but beware of selection
on DOUB data entered from AnalytiCalc.