>>>First time caller, long time listener.
>>>
>>>I have a utility I wrote in VB5sp3, that links in a number of Foxpro 2.6 DBFs into an .MDB file via DAO. Nothing special here, and all works just fine under Win95/98. However, when I run my utility on NT 4.0 sp4/sp5, I get the dreaded Dr. Watson c0000005 data access error. On a lark, I separated the .CDX files from the .DBF directory, and found that everything then worked. I suspect that the header info in the DBF contains associated CDX file info, and attempts to open it. Does anyone have any thoughts as to why this might cause an error on NT?
>>>
>>>I've tried recompiling my utility with VB60sp3, as well as applying the latest MDAC from Microsoft, but no joy. Adding .INFs for the .DBFs had no effect. I read somewhere that DCOM for NT is installed automatically with NTsp 3 or 4, but my knowlege of NT is rather limited. I do know that the workstations I'm running have no admin restrictions. I hope to avoid copying the .DBFs into a separate directory, as it is a distributed utility. Thanks in advance.
>>
>>James, I think I can help. I had a not too dissimilar problem with a FPW2.6a application compiled on a 16 bit machine. When I installed it on a 32 bit WIN95 machine my indexes failed - I do not remember the exact failure but it was due to the fact that the CDX's were built on a 16bit OS and not a 32bit os.
>>
>>My solution - I setup an "intall" column on my configuration table (which does not use a CDX) and set it to .t. When the installation first executes, I check to see if this flag is on. If it is I execute a udf() that indexes (not reindexes), builds all index tags on all tables from scratch. That worked!
>>
>>Try that - I suspect it may solve your problem. My humble apologies if it does not.
>>
>>Carl
>
>Carl,
>
>Thanks for the reply! Unfortunately, I found myself up against a deadline on this one, and had to resort to what I would call a kludge workaround: Specifically, after prompting the user for the location of the DBFs, I copied them all (behind the scenes, and sans CDXs) into the utility's directory, and linked to those DBFs without a problem. There was only a slight delay while the copy takes place, and there may even be a performance increase in cases where the original files are on a server (and the utility's directory is local).
>
>As to your suggestion: It sounds on target and fully in keeping with the joy of maintaining legacy code. Unfortunately, from this end, my Fox app appears to use its existing CDXs correctly, so I'm not sure if the 'destroy and rebuild' approach will work in this case. Still, I hate to give in so quickly to a problem without knowing it's true causes, so I'll pull out the earlier version of my utility, try your idea, and post my findings.
>
>Again, much thanks for your solution. This really is my first post, so please pardon the replication of the message. Hopefully I'll get the hang of this site in short order.
>
>Regards,
>Jim

Jim, no problemo. Yeah, I has to use this technique and it ALWAYS works. It totally solved my problems.

Let me know how it turns out.