Hi Pete

I have a couple of points to make in response to your 2-cents worth

> The two primary differences between the two are:

You omit to mention that OLEDB is COM based and is, therefore, only available on Microsoft Windows Platforms. As soon as you need to access a non-windows based platform you are back to ODBC (yes, I know there are OLEDB Providers for non-windows systems but they are just 'generic' providers - i.e. COM Wrappers around ODBC!)

> Now on top of the points above folks here we have a user that by his thread posted is
> using VFP 9.0. We all know that using the non-updated VFP ODBC driver many of the
> new field types that have been introduced are not supported using the VFP ODBC driver.
> This all comes to a head as we now want to start to take advantage of such field types
> as auto-incementing fields...etc... etc...

But this only applies to ACCESSING VFP Data using ODBC from other applications. In the context of using ODBC to access OTHER data stores this is totally irrelevant. Why would you use ODBC to access VFP data from VFP?

Since the advent of the "2000" model, other MS applications (e.g. Office and latterly .NET) have been designed around using OLEDB directly (as opposed to DDE which they used to to use) and that is the real reason why MS have not developed the VFP ODBC driver further, and are developing the OLEDB Provider instead.

>> Can I setup the DSN in VFP code, yes I can... do I need to added code, not me.

Come on, Pete, this is a red herring. As you know the easiest way to set up DSNs is to export the data from a REG file to a central location that is checked by the application at startup. When a new REG file is posted the App simply uses ShellExecute() to update the local user's DSN information. No additional code is involved!

This is especially important if you are running on a server 'farm' as opposed to a single machine. DBAs can, and do, move databases between servers (for patching, load balancing etc). The DBA can simply export an updated REG file and users, when they next log in, get the correct updated location information. This is MUCH harder to handle any other way!

> Do I want ODBC connections residing on 1000 workstations that any user with a bit of expereince can use.

First, this assumes that they are visible to the user. If you don't add the entry to the relevant key the connection is not visible and, since it does not include UID/Password anyway all it gives them is the name of the database, the server and the driver! Hardly a major issue surely?

I am not necessarily disagreeing with you, but, like me, your point of view is colored by your experience - and my experience is different.

I routinely integrate data from Windows and Non-Windows environments into Web Services created in VFP. In this environment OLEDB has proven slow and, in some cases, simply impossible. ODBC from VFP is fast and efficient and the fact that it is limited to SQL Relational Databases isn't an issue because that is all that I am interested in accessing this way.

I really don't need to talk to Excel Spreadsheets, or Word Documents or Outlook Folders. If I did,. I would use the appropriate tool - which might well be OLEDB. But as I see it, it is not "one or the other" or even "one size fits all"!

Of course, if I were building a .NET App to access SQL Server I would certainly NOT use ODBC, but I am not doing that either. I still think, and the evidence I have from my own daily work supports my view, that ODBC is still best way to access external RDBMS from within VFP.

Regards
Andy Kramek
Microsoft MVP (Visual FoxPro)
Tightline Computers Inc, Akron Ohio, USA