Re: C-ISAM reestablish position

(Roy Hasselman) writes: >Because points of return are >virtually infinite, I can't see how multiple channels can help me there. >I apologize if I bring up a well-known C-ISAM limitation, but I am new to >working with C-ISAM and was hoping to be able to do the same type of thing I >can do easily with another file manager (Btrieve). If you had no duplicate keys, wouldn't this problem go away? So disambiguate your own keys with a database record number or something. It's difficulties like this that led me to leave duplicate key support out of MY isam :-). It's hard to define good semantics for duplicate keys (e.g. when you delete dup #5, do the higher numbers move down?). It's a function that is trivial to accomplish by the user by appending a database record number or even a simple counter. There is a potential to add overhead even for indeces which have no duplicates. And there are a variety of possible implementations, each of which is problematic in some cases. For example, you can build special duplicate subtrees, add counters, add database record numbers, etc. Finally, if you hide the disambiguating data from the user, you have to add traversal commands that expose it anyway and complicate traversals. (get next duplicate, or get nth duplicate, or skip to end of duplicates). All of these considerations convinced me that duplicate key support "fills a much needed-gap" (Dennis Ritchie?). Alan Wendt EZLink Internet Access