| 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 |
Hi,
I am developing an application which holds employee details.
These details are held in an RMS Indexed file.
The segmented key field is SURNAME, FIRSTNAME. This key is
defined in the FDL as DUPLICATES=Y.
e.g. SMITH FRED Sales
SMITH FRED Finance
There doesn't appear to be a nice unique field I can use, like
Badge Number. It's best to allow the User to see only the name
when selecting a record and in the menu select box. I guess I'm
best off sticking with a duplicate key.
Using an ENTRY and INDEX form, I can index every record in the
file. When pointing to the duplicate records, OA$SCROLL_KEY
values are identical, however I can still use the
OA$SCROLL_ADDRESS to gain the unique RFA RMS address.
All DSAB access to the record will be fine as I can use a the
format TEST$E_DUPKEY.field[OA$SCROLL_ADDRESS]. NEXT_SELECTED
uses the RFA, I don't see a problem with any multiple Xoptions.
With displaying the entry form, I have seen
/SAVE_START="SMITH ,FRED" but this will always use the
first match.
How may I call the original entry form using the RFA key to
uniquely name the record to uppear????
Can you think of any other problems I should consider. I guess
this isn't a common requirement, as I doesn't appear in any
documentation I have seen.
This application is to run on an ALL-IN-1 v2.4 installation, I
would like to know any relevant differences with v3.
Advice is appreciated.
Thanks, Robert.
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 766.1 | IOSG::WDAVIES | Winton Davies,IOSG | Thu May 28 1992 17:29 | 3 | |
Why not just use a timestamp or a MAKEFILENAME random key?
Winton
| |||||
| 766.2 | MAKEFILENAME is a nice idea. | SUBURB::TAFF::Wob | Robert Screene, UK Finance EUC | Mon Jun 01 1992 10:49 | 14 |
Hi Winton, Yeah, I could add an extra field to the already segmented key. However the main data-file may be created by many means, not necessarily under ALL-IN-1. The product is to be sold as being able to use any old file you put under it. Having to generate a timestamp varying value for the records may be difficult in some situations. Do you really think sticking with the duplicate primary key idea is a bad one? Thanks, Robert. | |||||
| 766.3 | Suggestion | SHALOT::NICODEM | Who told you I'm paranoid??? | Mon Jun 01 1992 14:49 | 10 |
I'd still follow Winton's suggestion, and do something to insure unique- ness of the key. In the first place, ALL-IN-1 doesn't support duplicate primary keys. Yes, there are many functions that *will* work; just don't try to walk through your records using .%NEXT, or something like that. To make it more "bullet-proof" from the ALL-IN-1 side (and easier to enhance later, when you *do* need to do something that you can't do today), you want to stay within the boundaries that ALL-IN-1 defines. F | |||||