Accesing a Foxpro 2.6 DBF with ODBC

[falconsight]

I'm using free tables from another application, that will be feed from a VB application.
I'm trying to connect to the database using de Microsoft dBase ODBC, buy receive this error:

[Microsoft][ODBC dbase drive] Too few parameters. Expected 5

I have used VFP ODBC driver with no problem, buy I'd like to use the ODBC that comes in Windows XP as default.

Thanks in advance

 

[dilettante]

It would help to see your connection string at a minimum.

These drivers are part of Jet 4.0 and meant to be used via Jet, so I'm not sure they can be used via MSDASQL (the ODBC shim layer Provider).

Or are you trying to use DAO here instead of ADO?

 

[JoeAtWork]

Post the code that causes the error.

 

[vb5prgrmr]

It is best to use the VFP ODBC driver and depending upon your needs you may want to set it up as a free table directory IF you are using DAO ODBC Direct. If using ADO then see

http://www.connectionstrings.com

Good Luck

 

[dilettante]

INFO: Desktop Drivers Not Meant For Access or DAO is a VB5-era article talking about some of these issues. It describes the relationship between Jet and some of its extended Installable ISAM drivers and contrasts these with standard Microsoft Desktop Drivers as we know them today.

For example:

DRIVER=Microsoft dBase Driver (*.dbf)

Is incompatible with a VB progam containing even a single line of DAO code. Even an unused "Dim D As Database" can lead to a problem.

Visual Basic or Visual C++ applications cannot have any DAO code at all if they are going to work with Desktop Drivers. In one support case, a Visual Basic application was converted from DAO to the ODBC API, but it was still getting errors when it attempted to use the Access ODBC driver. The cause was found to be that one DAO line, a dim database, had been left in the application. Even though this dim database was never actively referenced in the code, it was sufficient to load a DAO instance of Jet that caused problems for the Access driver's instance of Jet. The application worked correctly when the dim database was removed.

 

[vb5prgrmr]

Well, if that is meant for me...

I have a program that has been running for 7-8 years now that uses the VFP driver and not the dbase driver. Set to a free table directory and using DAO ODBC Direct. Works faster, with less hassle than the attempt at the ADO counterpart, and uses less memory. So I must have dodged a bullet when I picked that driver for my first test... whew, good to know!

 

[dilettante]

No, it was just a general commont on this subject.

As far as I can tell the VFP driver is fine. There is a good VFP OLE DB Provider available free from Microsoft too. I think that KB article was suggesting you avoid using the Desktop Drivers in a DAO program.

I guess I'm trying to figure out if the Jet Drivers and standard ODBC drivers differ in their parameter lists. That might be why the OP's error is occurring.

 

[falconsight]

Thanks for your answers... Sorry for not answering before...
The connection string that I'm using (and works) is:

    fox_conexion.ConnectionString = "Driver={Microsoft Visual FoxPro Driver};SourceType=DBF;SourceDB=C:\falconsight\csc\alf;Exclusive=No"

the problema arises when I use:

fox_conexion.ConnectionString = "Driver={Microsoft dBASE Driver (*.dbf)};DriverID=277;Dbq=C:\falconsight\csc\alf;"

I'm trying to use the second one, because I assume is the standard driver that comes with Windows, then no more driver installing is required... But if you recommend using a VFP driver, I will do so.

All the change arise from a problem with the record inserted thru SQL-INSERT, that not always are indexed. That is, the new record shows in the table, but some queries (in the FP26 app) can't show the new data until a manual reindex. It is a free table with about to indexes in a CDX.

By the way, I'm fixing a software by another programmer... And rather prefer to use ADO.

 

[dilettante]

Most people running an even halfway recent version of Windows should already have the VFP ODBC driver. To be sure I suppose you could package using the merge module at: Visual FoxPro ODBC Driver.

I'm not sure why you'd want to thunk through MSDASQL to use an ODBC driver from ADO though. Microsoft OLE DB Provider for Visual FoxPro 9.0 is newer, smaller, and more performant.

Using ODBC just adds another layer between you and the data:

MSDASQL: The Microsoft OLE DB Provider for ODBC (MSDASQL) is a technology that allows applications that are built on OLEDB and ADO (which uses OLEDB internally) to access data sources through an ODBC driver. MSDASQL is an OLEDB provider that connects to ODBC, instead of a database.

Your connection string is implicitly requesting "Provider=MSDASQL" when you use the syntax you showed.

 

[falconsight]

Thanks all forum members for your advice.
Definitively I'll use the VFP ODBC.
I've talked with my client and we are from one mind on this.