Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

OLEDB vs ODBC

Status
Not open for further replies.

chouna

Programmer
Mar 28, 2003
75
DE
I have just hurdled the ODBC giant and now I am hearing that it has gone the way of the dinosaurs and OLEDB is the way to go. Can anyone tell me how the old turtle compares with OLEDB, when I should start using the new technology and when I should be dropping the old? The same goes with CursorAdaptors vs RemoteViews.

Most of my work requires me to only come up with VFP front-end programs to query our SQL Server databases. Nothing more than that; not even updating tables in the database since it is an ERP. What are the advantages for me? Will my EXEs experience a quantum leap in speed and will I save more time in development once I put these tools into action?

 
Hello Chouna.

>> I have just hurdled the ODBC giant and now I am hearing that it has gone the way of the dinosaurs and OLEDB is the way to go. <<

>> Most of my work requires me to only come up with VFP front-end programs to query our SQL Server databases. <<

In that case, I would continue to use ODBC because OLEDB is going to give you cack an ADO record set which you will have to convert into something that VFP can use (that is, a cursor ;-) ) Since ODBC gives you back a cursor that VFP an use without further cobversion, in my humble opinion, this is the way to go.

I would also advise against cursor adapters and remote views. They make transaction management difficult ( at best) because you cannot manage the connections separately. You may want to consider downloading the (free) samples on my web site called "Class Based Data Management". It data classes are a wrapper around SQL Pass Through and we have used a version of them in several very large production applications.




Marcia G. Akins
 
Thanks for the insight Marcia. I'll check out the site.
 
Chouna,

I totally agree with Marcia. If ODBC is working for you, stick with it. Despite what you have read, it is likely to be around for a very long time -- especially in the SQL Server world.

Mike


Mike Lewis
Edinburgh, Scotland

My Visual Foxpro web site: My Crystal Reports web site:
 
Thanks Mike, that's very reassuring. The ever-developing technology in remote data-access is really making me feel like I'm missing out on the new age. Your and Marcia's comments gave me the confidence to even look further into what ODBC can offer just when I was about to flip the pages.
 
I agree that you should continue to use ODBC if it's working for you. So, how do they compare? OLEDB is usually faster than ODBC. ODBC works only with relational data, OLEDB works with any kind of data. ODBC can be used for remote views and SQL Passthrough, OLEDB cannot as it returns ADO record sets (RS), not cursors.

I disagree with Marcia that you have to convert the RS to a VFP cursor to use it. You can bind any VFP control, except the grid, to a RS and use it just fine.


Craig Berntson
MCSD, Visual FoxPro MVP, Author, CrysDev: A Developer's Guide to Integrating Crystal Reports&quot;
 
Hi Craig.

>> I disagree with Marcia that you have to convert the RS to a VFP cursor to use it. You can bind any VFP control, except the grid, to a RS and use it just fine. <<

Everyone is entitled to the wrong opinion ;-)

Having worked on a VFP application that did bind directly to fields in ADO record sets, I must tell you that it was a major PITA to:

1. Get functionality that you get for free in VFP when binding to fields in cursors

2. Avoid and trap for ADO errors.

Personally, I would never do it again.



Marcia G. Akins
 
Having worked on a VFP application that did bind directly to fields in ADO record sets, I must tell you that it was a major PITA

Again, I have to agree with Marcia. I've always found the whole idea of record sets to be unnecessarily complicated, compared to good old-fashioned VFP cursors.

Mike


Mike Lewis
Edinburgh, Scotland

My Visual Foxpro web site: My Crystal Reports web site:
 
Another agreement with Marcia and Mike.

I once created a control class to bind to RS and ADO.

It was as Marcia so aptly pointed out - a major PITA.

It worked since the actual data binding was to a control
and not the RS field.

The custom control then talked to a RS field that the
custom control had a ref to, but that's a lot of wasted
code in my opinion.

Darrell
 
I am taking my first step into the remote data world and would rather use ODBC. I have to take an ascii file and insert those records into an Oracle table. Do you have to create a DSN on each computer that runs this code?

Chris


[spin]
 
Chris,
Please start a new thread for this question. It'll make it easier for later searching and responding.

Rick
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top