Our office recently converted our operating system to Windows 2000 and 

upgraded our Microsoft Office to XP.  Since then, certain programming and 

queries that worked in Access '97 give unexpected errors in Access XP.  

Here's my latest perplexing one.



I have a dBASE III database (DBF) linked to an Access XP database.  The 

DBF's fields contain numbers, text, and one Yes/No.  When trying to 

perform a query on this DBF, I get the following error message:



"The search key was not found in any record. (Error 3709)"



Access XP help says:



"This error occurs when an ISAM SEEK is being executed and there are no 

matching values in the index."



I don't know what this means.



The same query worked fine in Access '97.  Furthermore, other DBFs that I 

have with more fields, including date and memo fields, do not get this 

error message... yet.



An odd thing is that if I query for one value, the error message appears 

immediately and the query does not run.  If I query for another value in 

the same field, the query starts to run (I see values for about two 

seconds) then the error message pops up.  The values that started to 

appear go away, and every field is populated by the error value "#Name?".



Any clues?  Thanks.



Greg Serrano

SerranoG@m...

Lansing, MI

Gregory,



It probably means that the value you used to look up was not found. Have you

tried your query against values you know are in the database? Are you using

ADO or DAO for data access. It may hinge on that also. Just trying to point

in some likely directions without having seen your code/logic.



Regards,



Walt

Walt,



<< It probably means that the value you used to look up was not found. 

Have you tried your query against values you know are in the database? >>



Both values that I know are there and those that are not give me the same 

error message.



<< Are you using ADO or DAO for data access. It may hinge on that also. >>



I'm not versed well enough to know ADO vs. DAO, but I do know that under 

References in the module, the DAO 3.6 library is checked.



Thanks.



Greg

Gregory,



I found a Knowledge Base article: Q290867 that I think pertains to your

problem.



http://support.microsoft.com/default.aspx?scid=kb;en-us;Q290867



Hope this is useful.



Walt

Walt,



<< I found a Knowledge Base article: Q290867 that I think pertains to your 

problem.



http://support.microsoft.com/default.aspx?scid=kb;en-us;Q290867 >>



This page, in turn, points to a page that allows one to download the Jet 

4.0 Service Pack 5.  I had done this prior to sending out my original note 

and I still have the problem.  However, the page you referred me to gave 

me a hint about what may be going on.



Access '97 used to prompt me for the index (NDX) files associated to the 

DBF when I would link my DBF files.  I would identify them and Access '97 

would create the INF for the DBF file.  Access XP just links the DBF file 

without asking for NDX files.



Am I to assume that Access XP finds the appropriate INF files on its own?  

How can I make sure that it's reading the appropriate NDX files that are 

associated with the DBF?  I have found no menu or dialog box in Access 

that does that.  Also, Access XP balks when I try to use the Windows 

ODBCAD32 Administrator to associate the NDX files with the DBF.



Thanks for getting me closer!



Greg

Greg,



If I recall correctly, Access XP dropped support for dbase indexes! I, too

use many .dbf files so my solution was to move them into access tables (with

approprate indexes) and then proceed as before.



I use DAO and get a rsDBF and skip through it and addnew into the access

table.



Like they say, "close, but no cigar"



Walt

Walt,



<< If I recall correctly, Access XP dropped support for dbase indexes! I, 

too use many .dbf files so my solution was to move them into access tables 

(with approprate indexes) and then proceed as before. >>



Typical.  Microsoft has a habit of chipping away useful and often 

necessary functionality with each new "upgrade" they create.  They want 

people to improve their db management habits but forget to realize that 

there are databases already out there created in "grandpa" applications 

that need to be maintained and used.



Fear not, this time, for the head of our IP unit has found the solution.  

And it's one of those "you must be kidding" solutions.



The database is a dBASE III file.  Using the DBU.EXE program that comes 

with dBASE III, I created a new dummy field.  It's not even a primary 

key.  I resaved the structure of the database.  From there I went back to 

Access, refreshed my link, and voilą the error is GONE!  I even used DBU 

to go back and delete the unnecessary dummy field, restoring my database 

its original structure.  The error is still GONE.



So that's all it took.  I bet I didn't even have to create the dummy 

field... I suspect I would just have to resave the structure of the 

database in DBU.



Greg

Greg,



Glad to hear of your solution and success. Mark one up for the good guys.



While I usually follow the old admonition, "Let sleeping dogs lie" my

curosity has been piqued. There were/are some subtle differences in the

header/structure of .DBFs between the original dBase, FoxBase, and Clipper.

I suspect that saving the structure using dBase may have flipped a byte one

way or the other.



Thanks for the feedback. Will file this away under "Good to Know"



Regards,



Walt