• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 592
  • Last Modified:

Converting from CRecordset (ODBC) to OLEDB

Our project has many MFC CRecordset derived classes used for accessing our backend SQL Server database. Our program runs on NT/95 machines.

Is there an easy way to switch to OLEDB in our environment? If not, does anyone know of any code that replaces the MFC CRecordset functionality? Does anyone have any other suggestions?

Thanks :)
0
SteveGTR
Asked:
SteveGTR
  • 6
  • 4
1 Solution
 
DanRollinsCommented:
I have played with ADO _Recordset and found it a royal pain to use -- all that conversion to and from BSTRs for one thing.  For another, CRecordset provides nice clean class member variables for each field... other alternatives make you use database field names (advantageous sometimes, sometimes not).  Also, C++ sucks at accessing even the simplest of COM objects... it's a real shame we need to write wrappers to make anything usable -- VB users laugh at our struggles).  

What is your goal?  That is, why do you want to switch from CRecordset to something else?  

-- Dan
0
 
SteveGTRAuthor Commented:
Good question Dan. One of our developers said that OLEDB is about 10 times faster than ODBC. I've done some testing and OLEDB is pretty fast. Our application consists of about 100 sites with their own databases. The sites replicate data to and from each other (two way merge replication). One of the problems we deal with is record ownership, i.e. who can update a record. Having a central database or a number of shared databases would resolve this issue. But, the access speed using ODBC over T1's or worse 56K modems would be painfully slow. We thought that the performance gained by using OLEDB could make this speed issue moot and that it could solve the record ownership issue.
0
 
SteveGTRAuthor Commented:
Good question Dan. One of our developers said that OLEDB is about 10 times faster than ODBC. I've done some testing and OLEDB is pretty fast. Our application consists of about 100 sites with their own databases. The sites replicate data to and from each other (two way merge replication). One of the problems we deal with is record ownership, i.e. who can update a record. Having a central database or a number of shared databases would resolve this issue. But, the access speed using ODBC over T1's or worse 56K modems would be painfully slow. We thought that the performance gained by using OLEDB could make this speed issue moot and that it could solve the record ownership issue.
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
SteveGTRAuthor Commented:
I finally see how these double comments occur. I submitted the comment. Did some work. Came back and pressed refresh. The browers asked if I wanted to repost and I said sure. Double comment...
0
 
DanRollinsCommented:
I would be surprised to learn that the use of OLE Db is that much faster than ODBC.  Perhaps in cetain types of operations, but probably not for standard db access scenarios.  

Consider that at some level, it boils down to passing an SQL command to some program that knows what to do with it.  You can wrap 100 layers of software around that and it won't put in dent in the time used up by network latency.

I can imagine that bulk operations and/or local caching and/or other settings w/could be optimized through OLE DB access.  But there might be simpler options -- such as selecting an appropriate cursor library or access mode when you open the database -- that would clear up performance problems.

I'll tell you this:  I'd certainly write up a proof-of-concept test suite -- and verify the accuracy of its results -- before I started converting my 100,000 lines of ODBC code!

-- Dan
0
 
SteveGTRAuthor Commented:
Dan, thanks for your input. Your point about converting mass amounts of code was my reason for submitting this query. The core of my question consisted in these three questions:

1) Is there an easy way to switch to OLEDB in our environment?
2) If not, does anyone know of any code that replaces the MFC CRecordset functionality?
3) Does anyone have any other suggestions?

I think you touched on question three and I really appreciate it. I'll pass along your comments.
0
 
DanRollinsCommented:
One thought on item 2...
A goodly portion of CRecordset's functionality is that the Wizard will build and maintain the data members (automatically connecting to the data source and obtaining field info and adding the data transfer mechanism).  Short of writing a custom add-in for VC++, I think you will end up losing this functionality.

-- Dan
0
 
SteveGTRAuthor Commented:
Well Dan, there have been no responses aside from yours. I appreciate your help and would be willing to give you the 300 points. Let me know and I'll do whatever you suggest. Thanks again :)
0
 
DanRollinsCommented:
If you are short on points, then feel free to delete the question.   However...

I suggest that you give me the 300 points and a grade of A.  Why?  Because an A cost you no more than a B or C and I need the points if I'm to reach #2 position in the MFC section top 15.

You will be assured that I'll jump in on your next question and you'll have the extreme pleasure of knowing that you contributed to a worthy cause :)

-- Dan
0
 
SteveGTRAuthor Commented:
Sold to Dan for 300 points!
0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 6
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now