CRecordset too slow
I am using a MFC CRecordset (ODBC consumer) and opening as a forward only. A standard select returns 50K to 100K of records for a 24 hour period.
On a local DB (low ping) this is fine, select + processing times under 2 seconds.
On a network DB (high ping) this blows out to 60-90 seconds (and this will be used from a remote site.....).
It appears the CRecordset still needs to communicate with the DB each time I move thru the records (slowing it down). Even using a SAO (snapshot) does not improve performance.
Any ideas to improve the speed?
Would moving to WIN32 help (anyone actually tried this)?
If I can get these queries down to an acceptable time I can colour this one done......
rsMain.Open(CRecordset::forwardOnly ,sSQL , CRecordset::readOnly | CRecordset::noDirtyFieldCheck);
A couple of ideas.
1. The web seems to think that OLEDB may be faster than ODBC. CRecordset only supports ODBC. If your database supports OLEDB, you could test the difference between ODBC and OLEDB connection strings with a script to see whether it is worth changing.
2. MSDN has something about Fetching Records in Bulk.
Of course Win32 should be faster, as You -> MFC -> Win32 -> Subsystem
Rather, You -> Win32 -> Subsystem
I tend to steer clear of MFC, mainly cause its bloated and a tad-weird ;)
I was trying to avoid the bulk version of CRecordset......
I am adding to a legacy app in C WIN32 with MFC dlls. DB is SQL Server 2005.
Looks like my connection is throttled to the DB server (thru the client's network) and this is slowing down my app on each call to advance the CRecordset. Running without this throttling the app performs well within the requirements (1-2 sec to assemble and graph the 50K of records).
I suppose the question was, by how much is WIN32 faster?
I suggest you take another look at MFC, I find many people are biased against MFC for no good reason.
Whats a few Kb on the size of the app when MFC saves me months of dev time?
I'm against MFC cause there is nothing wrong with getting down and dirty with Win32, there's really no middleman needed :)