>COPY TO (tablename) DATA (dbcname) FOR KEYMATCH(IndexExppr,TAGNO(Indexname),cAlias)

Note that, though it was kind of hard to see, but there is a NOT (!) preceding my INDEXSEEK, like:

...FOR NOT INDEXSEEK()

I could try KEYMATCH, but I don't believe it would be a good idea, since we're seeking records that have no match. Unless it's truly much faster at NOT finding a match than INDEXSEEK, and I doubt it would be, because KEYMATCH moves the record pointer, where INDEXSEEK doesn't (according to docs, anyway). Since we're looking at very large tables where there is frequently no match in my situation, the overhead of moving the pointer would likely have a serious perfermance cost, at a guess. That said, I'd really have to test to find out, you never know with these things, sometimes they surprise you.

But also, KEYMATCH has a couple problems (as noted in Hacker's Guide, TAGNO is one and moving the rec pointer is another.) It has been replaced by INDEXSEEK. KEYMATCH is an old dBase function which probably shouldn't be used unless one needs it desperately, is the implication in Hacker's. A serious memory leak with INDEXSEEK would be a good reason to use it, but I'm not convinced of that yet.

For someone having problems with INDEXSEEK, it's probably worth a try, I will agree with you there.