Code references creates a table for its results wwith the name projectname_ref.dbf (and cdx and fpt), if you do a project search. So there'd be a code references result table per project.
I'm quite sure there will be other DBFs if you don't search a prject but a directory, there are several modes in which code references can be used.
Well, either you're not searching the project, or a copy of the project without a copy of that table projectname_ref.dbf table (which is in the same directory as the pjx. Didn't you recreate a pjx from scratch? That'll not restore this projectname_ref table.
Anyway, it's true code references stores its results and if you don't find them again, it's not the end of the world, is it? I mean results become outdated, when code moves because of new lines of code or removed lines of code, the results can become wrong pretty fast when you explicitly make changes to the code locations found. Information about line numbers is not updated when you change the code, for example. So the only relevant results are the last results anyway.
The stored results are not accelerating searches, they are just stored results of what was correct at the time of search. You do experiencee faster searches after you did one, but that's not an effect of these stopred results tables acting as an index, that's simply caching what was read in the first search, which accelerates further searches, even for totally different search terms, VFP is just having a lo of the source code in cached memory the second and further times you search.
Well, if you sill would like to look into previous search results the best thing to do is earch for *_ref.dbf files, there's a chance for finding some of that.
Chriss