| Title: | *OLD* ALL-IN-1 (tm) Support Conference |
| Notice: | Closed - See Note 4331.l to move to IOSG::ALL-IN-1 |
| Moderator: | IOSG::PYE |
| Created: | Thu Jan 30 1992 |
| Last Modified: | Tue Jan 23 1996 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 4343 |
| Total number of notes: | 18308 |
I am working on an application that uses an index form to access a data
file created with a C program. The file has a primary key which is
in binary form. The associated entry form for this file has a .FILE
directive which describes the data using an .FDL that in turn
describes the primary key as data type "dbin4". This all appears to
work OK. The data displays in the index form in the proper order
according to the key sequence (actually I'm surprised that it does
work, given the scenario below).
The question is this: the customer would like to be able to actually
delete records from the file by using the index form. Normally this would
be pretty easy by referencing the selected record via OA$SCROLL_KEY and
doing a write delete. The problem in this case is that ALL-IN-1
doesn't appear to know diddly about binary keys. OA$SCROLL_KEY appears
to return the ASCII translation of the key value and this makes it
impossible to reference the record to delete it. Even if a C module
could be written to do the deletion, I can't figure out how to pass it
a proper key value.
Any flashes of insight would be appreciated. If it helps there is a
secondary RMS key that is unique that is not binary.
Thanks,
Bob Spangler
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1402.1 | Use the address field and maybe your secondary key as well | SANFAN::LESLIE_DA | Greetings & Solutions | Fri Sep 11 1992 18:28 | 16 |
Hi Bob...
I could be wrong (it's happened before ;*), but I believe you can pick up
the key address of a record using oa$SCROLL_ADDRESS (or somesuch), this
may be all you need to identify a specific record and do *any*
operation on it as you have done in the past. I had thought there were
some examples of manipulating index form named data with this kind of
construct. If nothing else, it should give you a way to get to the
secondary ASCII (non-binary) key.
I have been away from ALL-IN-1 programming for a while, so I can't tell
you which APR manual to find this stuff, but it's documented (I
believe) in the part which refers to DSABs and built-in fields.
HTH,
Dan
| |||||