ODBC DSN for a Visual Fox Pro database Table 1

[fchan]

Hi,

I'm having problems connecting to a Visual Fox Pro database table thats in a Free Table Directory on a (Novell) machine that is not that same machine (Windows 2000) that my webserver resides on.

I mapped a drive on my webserver machine to the directory containing my Fox Pro table (tasks.dbf) on the Novell machine.

Then I created an ODBC DSN using the Microsoft FoxPro VBF Driver (*.dbf).

When I view my asp page, I get the following error:

Error Type:
Microsoft OLE DB Provider for ODBC Drivers (0x80004005)
[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified

This is my db connection code:

dim dbConn
Set dbConn = Server.CreateObject("ADODB.Connection&quot
dbConn.ConnectionString = "DSN=TrackIt"
dbConn.Open

Does anyone have any suggestions?

Thanks.

 

[link9]

I would suggest using a DSN-less connection... I used to lean on DSN's, but have lately come to not like them so much (seeing as my servers have been moved around quite a bit lately)...

I'll share something I read on

http://learnasp.com

the other day, which makes connection strings a snap:

Go to the Win2k machine, and right click on the desktop --> New --> Text File

When the text file appears on the desktop, name it "dsn.udl"... it'll say "are you sure" -- you say yes.

Double click the file you just made, and select the left most tab... select foxpro from the list, and then click "next" -- enter all your connection parameters on the following screens, and then click finish. The wizard box will close, and the file will be on your desktop.

Open up a blank text file in notepad, and then drag the .udl icon into the document. Voila.... a dsn-less connection string will appear. Copy and paste it into your code, and you're off and running. Also, it creates the OLEDB string, which is better than the ODBC string.

So why go DSNless? Because it's faster -- whenever you use a DSN, your machine has to go look in the registry and find it before it can connect to the database, and all it's doing is pulling the flaky ODBC connection string that is not recommended for DSNless connections -- so not only is it slower, it's not as good as your OLEDB string.

Add to that the fact that you can store you dsnless connection string in your global.asa file and call when needed... and then if you change locations with your database, you just go change the connection string in one place, and all your scripts run perfectly, you're left with only one real option....

Just a bit of learning from a guy who just spent an entire week moving to a dedicated hosting environment and spewing forth enough curse words to make me have to go to church every day for five years trying to get everything working again. Take it or leave it.

good luck!
Paul Prewett

 

[ToddWW]

link9,

I read your post and that sounds very interesting. I use a Fox Pro DSN now and it seems to work fine. However, I'm always up for improving things so I tried it out. Only when I got to the list, Fox Pro was not an option.

Any thoughts ??

TW

 

[link9]

Well, hush my mouth on the OLEDB driver for foxpro... did a quick and dirty search with no luck -- and not in the method I described, so I apologize for that. However, here is what I did find at:

http://www.able-consulting.com/ado_conn.htm?f=ado_conn.htm#ODBCDriverForVisualFoxPro

With a database container:

oConn.Open "Driver={Microsoft Visual FoxPro Driver};" & _
"SourceType=DBC;" & _
"SourceDB=c:\somepath\mySourceDb.dbc;" & _
"Exclusive=No;"

Without a database container (Free Table Directory):

oConn.Open "Driver={Microsoft Visual FoxPro Driver};" & _
"SourceType=DBF;" & _
"SourceDB=c:\somepath\mySourceDbFolder;" & _
"Exclusive=No;"

and you can use server.mappath(virtualPath) to get the physical path of your database if your on shared hosting or something.

good luck!
Paul Prewett

ps -- although this isn't OLEDB, it will still work faster for you than a DSN, and every little bit counts. ;-)

 

[ToddWW]

Thanks !!