> 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, USAHi Andy,
As I pointed out at the beginning of my post, "my 2-cents" and at the
end I identified there is no correct, or incorrect way. I think what I am trying to layout to the folks here at foxite this is a very complex question that seems simple when asked, but as you and I well know this is not a simple
question at all.
I tried to point out that the decision has to be based upon what you want to access moving forward. In my case we design a lot of applications with tight integration into Office 2003 stuff, so OLEdb has to be my method for sure.
I am accessing not only traditional RMDBS, but non-RMDBS data hierarchies.
Our corporate auditors have already identified that open ODBC connections
on end user workstations are unacceptable. Across out company dealing with
35 mills, some in Europe, a lot in the US and a bunch in Canada; I
an not going to even consider adding in ODBC connections across 35 mills
average 500 computer each for a total of 17,500 new ODBC connections and
registry hacks when I turn a new system up into production. Since most
of our applications "if not all" are run server-side, the last thing I
need is to monkey around with workstation configurations when deploying
the new application. Again, with a 1 GB network infastructure, I can
run all my applications off a server and seldom have to consider running
any application locally.
Then to add to all of this loose field types that I definately need to use
in VFP 9.0... naay not for me.
I think that we are really kind of in agreement here anyways as you mentioned;
"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 like these kinds of threads because connection to data
storage is a key issue within VFP. What methods a new user chooses
is important to what he/she wants to accomplish down the road. So
threads like this one provide varied opionions from experienced members,
working under different circumstances.
The way you choose to connect is a personal decision based upon the facts
at hand that the developer has to consider. I just layed all the cards
out on the table to better educate in making the correct decision.
So as a developer when sitting down with a new client one question that
should be asked is if the client envisions accessing non-database data such
as Excel, etc. If the answer is "Yes", well then choose the correct
method at the beginning of you development cycle, not 1/2 way through.
I have a web site I developed for a client that is using a VFP backend
and yes I used ODBC in this project. However, generally using ODBC for
me has become the exception to the rule.
Pete from the Great White North. (Only in Canada, ay.) Over and Out ...