"Dr. Ferenc Nagy" <[log in to unmask]> wrote:
 
>I have a detail set which is hanging on four master sets.
>M1 M2 M2 M4
>|--|--|--|
>    D
 
>The search items are K1, K2, K3, K4 respectively.
>If I issue a DBFIND with setname=D and item=K1 and key_value="V1" then the
>subsequent chained DBGET-s are going along the chain of K1="V1" values.
>The status vector will contain the pointers of the previous and the next
>D entry with the same K1="V1" value. How can I read the pointers of the
>other three chains i.e. the pointers to the previous and next same
>K2="V2", K3="V3" and K4="V4"?
 
It's easy: you do a DBFIND on whichever path you want info on, then do a
directed DBGET.  The DBFIND tells Image, "I want to work with this path now"
and the directed DBGET re-gets the current record -- but now it contains the
pointers for the path of interest.
 
 
>In other words: what is the undocumented DBGET mode, which reads the
>_whole_ media record (data and _all_ pointers) of a detail data set?
>What is the structure of the result? (I expect something like this:
>DATA: "K1", "K2", "K3", "K4"; POINTERS: ^K1, K1v, ^K2, K2v, ^K3, vK3 AND
>^K4, K4v.)
 
The undocumented mode is calling DBOPEN with an open mode of "-1"; this is
documented in the IMAGE handbook; the handbook also has examples using
DBDRIVER.  Another tool you might try using is a TELESUP utility called
SCALPEL that's used for fixing databases (or messing them up if you're not
careful).
 
>A related question:
>
>If I issue a DBFIND with setname=D and item=K1 and key_value="V1" then the
>subsequent chained DBGET-s are going along the chain of K1="V1" values.
>Now I call a directed DBGET and a DBPUT. Will go the next chained DBGET
>on the K1 chain?
 
Yes.
 
>Where does the system remember that the chained DBGETs
>are going on the K1 chain?
 
You got me.  Magic?
 
>When will it forget? At the next DBFIND?
 
At the next DBFIND *using a different path*
 
> What happens if I issue a chained DBGET (mode=5 or 6) without a DBFIND,
just
>after a DBOPEN?
 
Let me know.