Re: multiple file access in CISAM
Posted in 1992
In article <45@bbx.basis.com> russ@bbx.basis.com (Russ Kepler) writes: >I'm in the process if attempting an integration of the Informix CISAM >file drivers into another product [ ... ] Sounds very familiar so far! :-) >Is it possible to save isrecnum >following access and use that to start a *logical* access on another >isfd? It appears that isstart() may be called to set the physical >record number, is it possible and reasonable to continue a logical >access following that access? Yes, it can be done. If you want to use something other than the record number as an index (which seems likely), it is not clean or efficient. Indeed, it is a right pain. If you want to go to an arbitrary record and then continue your processing from there on some index, there is only one way I can find to do it: - set index to direct - isstart() on the saved recnum - save the data you get back - set index to the one you want - isread(ISEQUAL) on the data you saved - while isrecnum doesn't match your saved recnum, isread(ISNEXT) Of course, if you are using keys with no dups, the last step is unnecessary. Some sensible way to do this would be great, but C-ISAM doesn't appear to provide one. >If the foregoing is possible, what >happens if the record pointed to by the saved isrecnum is removed >or modified in the meantime? You'll get an error return somewhere along the way if the record has been removed. If it has been modified, nothing will change. >If the file is being accessed using 2 different isfds will record >locking function between the 2 handles? No. By the way, you are well on your way to discovering bug #12823. To save you the 6 weeks it took me to get anything useful out of Informix on this: The isrecnum variable is not returned correctly by isread() in several cases when the required record is locked by another process. Rather than use isrecnum, you can get the right value by using treeitem.it_ptr, given the following definitions: #define KEYSIZE 120 /* in 4.0, at least */ struct item { short it_flags; /* flag bits */ short it_totlen; /* total length */ short it_keylen; /* key length */ unsigned long it_dupnum; /* duplicate number */ long it_ptr; /* pointer */ short it_leadcnt; /* leading count */ short it_trailcnt; /* trailing blanks count */ char it_key[KEYSIZE]; /* key value */ }; extern struct item treeitem; Greatest thanks to aland@informix.com for this information. (Greatest raspberries to Informix Australia who were as useful as a fart in a spacesuit.) :-) -- _--_|\\ Craig Macbride <lhscmc@luxor.latrobe.edu.au> / \\ <s900387@minyos.xx.rmit.oz.au> \\_.--.*/ v