> > 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
>
>
> Hi 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 ...

Pete,

I like these kinds of threads ...

I have to agree with you on this comment. It is threads like this that allow us all to grow as developers. My rating to both you and Andy.

I am just now dealing with this exact issue. I have a new app under development (VFP backend) and if I were to go the ODBC route, I would have had it done by now - in fact, I have a working version of it using ODBC. The problem is that I want to be able to use VFP 9 field types and ODBC won't let me do this. In the ODBC version, I used workarounds to handle these advanced field issues (for example, instead of using an autoinc field, I used an integer field and created an insert trigger to generate the next PK value.)

I am unsatisfied with this solution however. I really want to be able to use these new fields so I am now reworking the app to use OLEDB instead. This has been a learning process for me (and continues to be.) Up till now (as Andy well knows,) I have been a strict SPT fellow (using data management classes based on Andy's excellent article) but with this app, I am now giving CA's a go. (Thank you Bernard for your excellent series in the articles section of this site.)

Pete, your comments regarding future needs is most appropriate. I am the fellow who has to make these sorts of decisions in our organization and I am staring this one in the face right now. Thanks to both of you for your discussion.

Ken
You shall know the truth - and the truth shall set you free. (John 8:33)