Glenn,

First of all, I did not see the memory leak (yet)

If you use INDEXSEEK for just looking up a record, you'll find that indexseek is not significant faster than SEEK, because they perform more or less the same action.

However, if you use INDEXSEEK to check if a certain key exists in a particular table, it might be better to use KEYMATCH() (whether or not in combination with SEEK())

If you do not want to filter the lookup table (and it does not contain deleted records or the index expression is filtered on FOR NOT DELETED()) and only want to check if a certain key exists, a single KEYMATCH() is far and FAR faster than SEEK() or INDEXSEEK()

If you do want to filter the lookuptable or it does contain deleted records and no filtered (for not deleted()) index expression is used, or you have to use the contents of the lookup table, BUT the hitrate of the lookup is less than e.g. 90%, you can use:

IF KEYMATCH( ... ) AND SEEK( .... )

The keymatch gives a significant performance advantage for non-hits on the indexkey expression.

NOTE: Some people might argue that the overhead of the KEYMATCH() function might burden performance, but when you test this, you'll see that the time to process the KEYMATCH command is nothing compared to the extra I/O SEEK() needs for non-hits. So overall performance with KEYMATCH is much better.

Walter,


>I have some programs which convert massive amounts (3M RECORD SETS) of data from flat ascii files into various related FP tables. In an attempt to improve performance I liberally used the SP3 command, INDEXSEEK as opposed to SEEk. I found that this function exhibits a nasty memory leak when used in a high volume repetitive loop and have since converted back to SEEK.
>
>Has anyone else experienced a problem with INDEXSEEK?