Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win


ODBC MFC CRecordSet performance

Posted on 1999-01-21
Medium Priority
Last Modified: 2008-03-17
I am writing a family tree program in Visual C++ 4.0 using local ODBC links to Paradox 5.0 or Access 97 (the final choice is immaterial unless one turns out to be significantly better than the other).  I am using CRecordSet derived objects to provide the data needed to draw the tree on screen.  The idea is to navigate around the tree with the mouse, each double click redrawing a restricted portion of the tree focused on the person where the click occurred.  Unfortunately it takes about 17 seconds to redraw, the delay being caused by requerying the recordsets.  This makes the program somewhat unusable and I haven't yet even created all the recordsets that will eventually be required.  Can anyone suggest ways I might speed things up a bit?

Things I have already tried include the following:

* Closing recordsets in between use and opening them again when a requery would be needed.  This was suggested by a company called DevCentral on the grounds that a lot of open recordsets take up a large amount of RAM.  Unfortunately this approach takes even longer than when they are left open and requeried as necessary.

* Using a single global CDatabase object and passing this to the CRecordSet constructors instead of letting them create their own individual connections.  This has been my approach from the start and was also suggested by DevCentral.

* Using queries which reside in the database instead of submitting SQL from the C++ program.  I have been unable to get Access queries to accept parameters submitted via ODBC (they expect to present interactive users of Access with a dialog box) and have failed to access Paradox queries at all via ODBC.  Calling a query from Access which did not require parameters still took about the same length of time.

* Using less recordsets to obtain the same information.  I wrote a single recordset with a long cumbersome SQL statement to obtain all of the information required in one go but because there were so many more fields to return this still took as long as using lots of smaller recordsets.

* Only obtaining minimal information to draw the tree, querying for additional information as required (photos, text entries etc).  In fact the information so far being requested is minimal because I am still testing prototypes of this application.  If I used any less information there would be nothing to display at all.

* Not changing details of the recordset in between requeries, except for the parameter data member(s).  This was suggested in the Visual C++ help system and is what I am doing in any case.  The fact that the help system mentioned performance at all leaves me somewhat pessimistic.

Is ODBC always this slow or am I not using it right?  Any help or suggestions gratefully received.

Phil Hudson
Question by:Hudson
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions

Expert Comment

ID: 1026319
If memory serves me right issuing ODBC SQL commands causes all data to be passed to the local SQL engine for that engine to do a sort. Try using Native SQL code or revising you Database so that it contains Views that present the data in the order that you want and access via those views

Accepted Solution

jpk041897 earned 400 total points
ID: 1026320
There are a few tricks you can use:

1.- MFC uses the Jet engiene to communicate to ODBC, which means that you are using 2 layes of abstraction to contact the DB. With Paradox you don´t have a choice but with Access you can avoid one layer by using the DAO calls instead of the ODBC calls (the changes in code are minimal). Using CDaoRecordSet instead of CRecordSet should give you about a 30% increase in performance. It will also allow you to compact the DB as needed (which you can't do with ODBC).

2.- The ODBC drivers for both Access and Paradox do not support stored procedure calls, which is why your attempts to call queries failed. On the other hand, Access VBA is OLE2 compliant, so you could make the calls in that fashion, though if memory is a concern, this could be counter productive.

3.- Another way you can increase performance is to set up a hashing scheme. If your Primary key is a string, your avarage test will require half the lenth of the key tests to determine if it passes or fails the SELECT clause.

If you add a field to your table that contains, say the ASCII sum of the characters that make up the key, you could querry on that (integer) value instead. That will make all tests 4 bytes long (which is generaly a lot shorter than half the string length). The resulting record set will return some false positives ( abc produces the same integer as cba) but these can be eliminated localy with calls to strcmp before you display them to the list.

Hope these ideas help.

Author Comment

ID: 1026321
You state that using DAO instead of ODBC will give about 30% increase in performance - hence my pessimistic comment on Friday about giving up and writing my own internal database.  In fact I have now implemented it with DAO and what was taking over a minute now works in much less than half a second.  I'm now learing about QueryDefs since they claim to make things even faster.  Thanks for that suggestion, and the others, you've really saved the day here!

Featured Post

What is SQL Server and how does it work?

The purpose of this paper is to provide you background on SQL Server. It’s your self-study guide for learning fundamentals. It includes both the history of SQL and its technical basics. Concepts and definitions will form the solid foundation of your future DBA expertise.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

In this series, we will discuss common questions received as a database Solutions Engineer at Percona. In this role, we speak with a wide array of MySQL and MongoDB users responsible for both extremely large and complex environments to smaller singl…
What we learned in Webroot's webinar on multi-vector protection.
In this video, Percona Solution Engineer Dimitri Vanoverbeke discusses why you want to use at least three nodes in a database cluster. To discuss how Percona Consulting can help with your design and architecture needs for your database and infras…
This lesson discusses how to use a Mainform + Subforms in Microsoft Access to find and enter data for payments on orders. The sample data comes from a custom shop that builds and sells movable storage structures that are delivered to your property. …
Suggested Courses

636 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question