Visual FoxPro ODBC Stop Working???

[Soleil525]

I'm using CR8.5 connect to a Visual FoxPro DB via Visual FoxPro Driver. The DSN is working fine up until yesterday. When I open Crystal Designer, then select the DSN that is pointed to the VFP db, I receive this error message: "ODBC error: [Microsoft] [ODBC Visual FoxPro Driver] Cannot open file c:\temp\0v580004.tmp (the file name is different everytime I attempt to connect to the db). I click Ok then a second message appears "Server has not yet been opened". I deleted the DSN and re-create a new DSN using Visual FoxPro Driver but it still does not work. My Oracle and SQL DSNs are working fine. I think the Visual FoxPro Driver is corrupted??? Can you please provide your input. Your help is greatly appreciated. By the way, my OS is Windows NT workstation 4.0.
TIA

 

[jonscott8]

Is the VFP DB on the same or a different machine as the DSN?

Open your DSN, under Options - make sure the option "Fetch Data in Background" is NOT checked. If it is, uncheck it.

What version of the VFP ODBC driver are you using?

I believe there was an older version that would report a "cannot open file" error incorrectly when the error should be "file in use". Is anyone else accessing the DB at the same time as you? Jon Hawkins

 

[Soleil525]

Jon,
Thank you for a quick respond.
1. The DB is resided on the server
2. I already unchecked the "Fetch Data in the Background
3. The VFP ODBC Driver version is V6.01.8629.01

As I mentioned in the message, I was able to use this driver up until yesterday. I don't know what went wrong with my machine. My co-worker was able to setup the connection to the DB on his machine without problem. Any other suggestion of how I go about troubleshooting this? I already spent two days on this issue so any suggestion at this point is greatly appreciated.
Thanks,
Bryan
p.s. I did re-installed Visual Studio on my machine but it does not make any different.

 

[Soleil525]

Any other suggestion???

 

[jonscott8]

Try this,
Copy the VFP DB to your local PC, create a new DSN pointing to the local DB. Then, try your Crystal Report again using the new DSN. Jon Hawkins

 

[Soleil525]

Jon,
I did as you suggested. I have also uninstalled and reinstalled Crystal report. In addition, I removed the existing VFPODBC.DLL from my machine, downloaded a new version from MSN site and installed it. I still get the same error message. I hope I don't have to reload my machine. Please let me know if you come up with anything.
thanks,
Bryan

 

[DEDMOD]

Have you checked the VFP database itself to make sure it's ok? That is, did you go to the server (or have someone go to the server if it's not close by) and actually open it an make sure the data, indexes, etc. are ok?

It seems unlikely you haven't, but I don't see you've actually said so, so figured I'd better ask. Dave Dardinger

 

[Soleil525]

Dave,
I don't think the problem is on the server. I have asked my co-workers create a DSN that use Microsoft Visual FoxPro Driver on their machine and pointed to the DB on the server. They were able to do so and connect Crystal to the DB via the DSN without problem. The error only occur on my machine.

 

[jonscott8]

Can you access the DSN from something other than Crystal? Attempt to open the DSN in VFP from your machine.

? SQLCONNECT("MyDSN&quot

If this is NOT successful, go into C:\temp and delete all the .tmp files. Then try the connection again in VFP. Jon Hawkins

 

[Soleil525]

Jon,
The C:\temp dir are three files in this dir
~DF1969.tmp
~DF1973.tmp
~DF204c.tmp
The system will not allow me to delete these files.

How do I open the DSN in VFP?
Thanks

 

[DEDMOD]

The simpliest way is just to try creating a remote view using the DSN. Open up a database in a project manager (project doesn't matter) and click Remote view / new and then select Available Data Sources Find your DSN and select it. If things are working as they should, the tables in the database you're using should appear for you to add to the view. If it doesn't show up any tables or give an error, then something's wrong with the DSN. I'm not sure where you can access the DSNs in NT 4, but in Window's 2000 they're in the Control panel under Administrative tools / Data Sources I just went in and modified one I had which didn't work because I'd changed my SQL Server to SQL Server 2000 a while back and hadn't changed the SQL name. You don't apparently have exactly that problem with your VFP database, since you recreated it and still had the problem, but this should let you decide between the Crystal side and the ODBC side being the problem. Dave Dardinger

 

[rnathan]

Even though this thread is about three months old, I decided to respond because I was having a similar problem last week and searching for a solution in some of the news groups and MS website. Didn't find anything except this one which came close but no proper solution. I called MS-Tech Support and this is the solution they provided. It works.
- Open a DOS window and type the following at the C: prompt.
- attrib -S C:\temp
Basically, you have to remove the system attribute that prevents writing, creating or opening a .tmp file in the temp directory. C:\temp could be replaced by whatever directory you are having problem with. For more info. please visit the following link.

<

http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q308215>

Rita

 

[rgbean]

Rita,
Most interesting, however I find it curious that the article didn't indicate WHAT caused the system attribute to be set in the first place! I've got a couple users (and one developer <s>), who have this problem every couple weeks. Neither uses the VFP ODBC drivers - it's VFP or a VFP app that actually &quot;dies&quot; when it tries to open it's temp files. We've never been able to isolate the uniqueness of the two users (out of hundreds) or the developers (1 of 12).

Rick

 

[rnathan]

Rick,

Yes, the article doesn't specify what causes the system attribute to be set. According to MS-Tech support, it is the third party applications you install or something you download from the web that sets the system attribute. I am not sure how far this is true. My users didn't install anything recently. My application is written in VB and I am using VFP ODBC driver to access VFP database. Thanks for the input.

Rita