MSAccess ODBC driver slow-down on upgrade from VC++ 5.0 to 6.0

MSAccess ODBC driver slow-down on upgrade from VC++ 5.0 to 6.0

Post by Christopher F. Conne » Thu, 10 Dec 1998 04:00:00



As "stupid" as this sounds, you may not be dispatching messages in your
application loop when its in the foreground.. does the application "run
faster" when you move your mouse around on the logger screen when it has the
focus? If this is the case, then you need to see where your messages are
being dispatched in your app... perhaps they are going all the way up to the
"root" rather than being dispatched directly to the thread responsible for
it. Since I am not a C++ guru, and actually I am more or less in the
learning stage, I apologize for not being able to say this any more clearly
than I can. I hope someone else will elaborate for me on this.

=-Chris Conner


>Greetings,

>I am relatively new to this news group, having started using it only
>about two weeks ago.  I posted a problem we have had but got no response
>so I would like to try one more time.  I would really appreciate any
>help, since we still are no closer to resolving this than we were when I
>made my original post.

>Platform: Win95, ODBC MSAccess, VC++ 6 (in Visual Studio Enterprise Ed.)

>We have developed an application that uses multiple threads (each
>running at normal priority) to implement a Win95-based remote data
>logger.  We are using CDatabase and CRecordset-derived classes to store
>and remotely retrieve data from the logger via modem-based serial
>communications.  The underlying database format is MSAccess.

>We recently upgraded from Visual C++ 5.0 to Visual Studio 6.0 (which
>includes Visual C++ 6.0).  Before the upgrade, opening a recordset took
>a fraction of a second.  Since the upgrade, it takes ten seconds or more
>to open the same recordset.  Update()s, AddNew()s, etc. slowed down
>similarly.  We tried recompiling the executable using the new Visual C++
>6.0 compiler, but the results were the same: it still took ten seconds
>or so to open, update, etc. a recordset.

>We noticed something very odd: this slowdown only happened when our
>logger application was the foreground process (i.e., one of its windows
>had the focus).  Whenever any other application (Word, Eudora, Netscape,
>...) was the foreground process, our logger's recordset operations all
>worked as fast as they did before the upgrade.  We toggled the focus
>back and forth between the two applications, and the recordset
>operations always were slow when our
>logger application had the focus and they always were fast when any
>other application had the focus.

>After trying a number of other things, we finally compared ODBC driver
>versions (using the ODBC Data Source Administrator).  Before the
>upgrade, (when we were running Visual C++ 5.0), ODBCJT32.DLL driver file
>was version 3.50.360200, dated 12/2/96.  After we installed Visual
>Studio 6.0, the ODBCJT32.DLL file was version 3.51.171300, dated
>5/31/98.

>We copied the older (12/96) version of the driver into our
>Windows\System directory.  After that, when we ran our logger
>application, recordset operations were fast, whether our application had
>the focus or not.  We copied the new (5/98) version back into the
>Windows\System directory, and the recordset operations again slowed down
>to a crawl whenever our logger application had the focus.  We copied the
>versions back and forth several times and confirmed that this was what
>was making the difference.

>Do any of you have an idea as to why we would see this bizarre
>behavior?  We could understand if one version of a driver had a little
>different speed, but we can't believe it normal for the speed difference
>to be orders of magnitude and we also can't believe the difference would
>show up only when our application did *not* have the focus.

>TIA for any light you might shed on this.  Please send responses not
>only to the newsgroup but also to my e-mail, by removing the
>_DONT_SPAM_ME and the _NO_SPAM parts shown below.

>Carl Benner


 
 
 

MSAccess ODBC driver slow-down on upgrade from VC++ 5.0 to 6.0

Post by Carl Benne » Thu, 17 Dec 1998 04:00:00


Chris,

Thanks for your response.  I looked at the message routing, but it follows the
standard MFC mechanism.  Also, moving the mouse around had no effect on speed.

I have what may be two dumb questions:
    1) What messages need to be dispatched to the ODBC driver?
    2) If my application were keeping messages from getting to the ODBC thread,
why would this change when I substitute one version of the ODBC driver DLL
version for another?

Thanks,
Carl


> As "stupid" as this sounds, you may not be dispatching messages in your
> application loop when its in the foreground.. does the application "run
> faster" when you move your mouse around on the logger screen when it has the
> focus? If this is the case, then you need to see where your messages are
> being dispatched in your app... perhaps they are going all the way up to the
> "root" rather than being dispatched directly to the thread responsible for
> it. Since I am not a C++ guru, and actually I am more or less in the
> learning stage, I apologize for not being able to say this any more clearly
> than I can. I hope someone else will elaborate for me on this.

> =-Chris Conner


> >Greetings,

> >I am relatively new to this news group, having started using it only
> >about two weeks ago.  I posted a problem we have had but got no response
> >so I would like to try one more time.  I would really appreciate any
> >help, since we still are no closer to resolving this than we were when I
> >made my original post.

> >Platform: Win95, ODBC MSAccess, VC++ 6 (in Visual Studio Enterprise Ed.)

> >We have developed an application that uses multiple threads (each
> >running at normal priority) to implement a Win95-based remote data
> >logger.  We are using CDatabase and CRecordset-derived classes to store
> >and remotely retrieve data from the logger via modem-based serial
> >communications.  The underlying database format is MSAccess.

> >We recently upgraded from Visual C++ 5.0 to Visual Studio 6.0 (which
> >includes Visual C++ 6.0).  Before the upgrade, opening a recordset took
> >a fraction of a second.  Since the upgrade, it takes ten seconds or more
> >to open the same recordset.  Update()s, AddNew()s, etc. slowed down
> >similarly.  We tried recompiling the executable using the new Visual C++
> >6.0 compiler, but the results were the same: it still took ten seconds
> >or so to open, update, etc. a recordset.

> >We noticed something very odd: this slowdown only happened when our
> >logger application was the foreground process (i.e., one of its windows
> >had the focus).  Whenever any other application (Word, Eudora, Netscape,
> >...) was the foreground process, our logger's recordset operations all
> >worked as fast as they did before the upgrade.  We toggled the focus
> >back and forth between the two applications, and the recordset
> >operations always were slow when our
> >logger application had the focus and they always were fast when any
> >other application had the focus.

> >After trying a number of other things, we finally compared ODBC driver
> >versions (using the ODBC Data Source Administrator).  Before the
> >upgrade, (when we were running Visual C++ 5.0), ODBCJT32.DLL driver file
> >was version 3.50.360200, dated 12/2/96.  After we installed Visual
> >Studio 6.0, the ODBCJT32.DLL file was version 3.51.171300, dated
> >5/31/98.

> >We copied the older (12/96) version of the driver into our
> >Windows\System directory.  After that, when we ran our logger
> >application, recordset operations were fast, whether our application had
> >the focus or not.  We copied the new (5/98) version back into the
> >Windows\System directory, and the recordset operations again slowed down
> >to a crawl whenever our logger application had the focus.  We copied the
> >versions back and forth several times and confirmed that this was what
> >was making the difference.

> >Do any of you have an idea as to why we would see this bizarre
> >behavior?  We could understand if one version of a driver had a little
> >different speed, but we can't believe it normal for the speed difference
> >to be orders of magnitude and we also can't believe the difference would
> >show up only when our application did *not* have the focus.

> >TIA for any light you might shed on this.  Please send responses not
> >only to the newsgroup but also to my e-mail, by removing the
> >_DONT_SPAM_ME and the _NO_SPAM parts shown below.

> >Carl Benner



 
 
 

1. MSACCESS driver slowing down?

I installed the D3 MSACCESS driver a while back, and the performance
seemed OK. I've just gone back to it after a hiatus, and it has become
EXTREMELY slow, and periodically crashes the application - for
instance, when my Delphi 2.0 client application executes a
Tdatabase.Open (pointed to the MSACCESS alias) it either runs slowly
or hands. Database Explorer (the BC++ Builder C/S version) can open
the database fine, as can me D2 application some of the time (I have a
real mish-mash of stuff installed on this machine).

Anybody have any ideas?

Also, I've upsized a database from MS Access to InterBase using the
Borland Data Migration Tool, which appears to have recreated all
indexes and so forth. However, the Interbase interface is also very,
very slow, and wasn't earlier.

Will
|-------
| William Crawford, Data Express Software

2. Help!

3. HELP: Problems with different ODBC drivers on different machines with same applications (VC 5.0)

4. sql select

5. New ODBC driver slows down to a crawl

6. deductive databases

7. crystal report produces ORA-01007 error

8. Upgrading SQL Server 6.5 to 7.0 and Upgrading VB 5.0 to 6.0

9. Linker problem between Dev studio 5.0 and Visual Studio 6.0 VC++

10. upgrade to sql2000 slow down the query

11. Chunks down after upgrade (4.1 -> 5.0)

12. help ...paradox 5.0 slowing down