Get_Equal / Get_Next

[senorbuckwheat]

Howdy,

Using the Btrieve API, I do a GET_EQUAL command on a Btrieve table. I set the OpCode, PosBlock, DataBufLen, KeyBuffer, and KeyNumber and then execute the command.

If a record is found that matches the key, I do some processing and then do a GET_NEXT to get the next record that matches the key and so on.

The problem is that the GET_NEXT gets records that does not match the key after all the records that match the key have been read.

It seems once it establishes a position in the file based on the key during the GET_EQUAL, it just keeps reading records sequentially using the GET_NEXT without regards to the key.

I work around it by checking the returned record values against key values after each GET_NEXT and then breaking when they do not match. But that seems to defeat the purpose of a GET_EQUAL,GET_NEXT using a key value.

Any suggestions would be welcomed.

Thank you.

 

[Vancouverite]

Actually, that is how GET_EQUAL/GET_NEXT are supposed to work. GET_EQUAL, as you know, finds a match based on the key. GET_NEXT simply steps through the table based on the index specified.

Why work this way? Consider an index by date. YOu want to retrieve all of the records between 01/01/2003 and 01/31/2003. To do this, you could GET_EQUAL for a record with a 01/01 date (usually, you would actually do a GET_GE, but let's use GET_EQUAL for this example). Then, do a GET_NEXT, checking the date until it is greater than your selected maximum value (01/31 in this case), after which you exit the routine.

If GET_NEXT worked as you were thinking it should, you would have to GET_EQUAL for 01/01, GET_NEXT until a non-matching condition was reached, then GET_EQUAL on 01/02, GET_NEXT, do 01/03, 01/04... 01/31. This is significantly more code.

Try using the Extended Ops (Get Next Extended), which does a Get Next with a filter so that only records matching what you want are returned.