Looking for suggestions on how to retrieve a record with a three part key.

I am converting an Arev system to OI. A file has a three part key. When the records were written in AREV with only two key parts provided they appeared like this - "2*4001". When OI tries to retrieve them (form attached to a database) it puts the key together like this "2*4001*". The last astrisk of course changes the key. How can I interrupt this process and modify the key value.

Steve,

We've run into this problem as well but decided against trying to maintain the two-part and three-part keys in the table. We chose to convert all two-part records to three-part records and be done with it. You could interrupt in various ways but then you have to work out a scheme to avoid the record from being written back using only two-parts as well.

At the moment the only method I can think of that I know will work is to programmatically control the reading/writing using either a non-databound form that simulates a databound form or by intercepting the READ and WRITE events of the window (i.e. before the System event handler kicks-in) and modifying some of the common variables. You still may have to populate the controls yourself however. Perhaps others have already gone down this path with an elegant solution (Sprezz? Don M.? Oystein?)

[email protected]

SRP Computer Solutions, Inc.

Don,

Thanks, I already considered that but was trying to avoid it. How many different areas in other programs…….ah well. Hopefully others will chime in and the super solution will appear .

Don, Steve,

Sorry - my experience with multi-part keys is limited. The few tables with multi-part keys that I have in my apps haven't even got any associated forms. (And because of that I sometimes even use a different delimiter character than the asterisk.)

Don's advice of getting rid of the problem once and for all sounds attractive.

But are there any objections to that strategy? Is the table shared with the Arev app so the keys can't be changed? If so - could the problem be solved with an MFS??? (My experience with MFS's is limited too. At least I've never made an MFS that deals with changes in keys.)

Or is there something that makes the problem simpler than it seems? You (Steve) mention the problem when rows are read from the OI app. Does that mean the table is only read?

- Oystein -

Oystein…

There are no immediate plans to share the table. But changeing the key means also changing a number of RBASIC programs and having our users run the conversion program. I was just trying to avoid all that. It looks like I may not be able to. Unless RTI wants to make this work the same way that AREV does. Although I suspect that it might be to late. The problem is that the '*' delimeter is placed in the key when the third component is null. In AREV it is not.

If I were you, I'd opt for the MFS approach. FWIW, I think the results would be more predictable and certainly less of a headache. Even if you decided later to share the table, the MFS would work correctly.

Don M.

View this thread on the Works forum...