Old problem - slow XP clipper + AdsDosIP problem/solution

[peterk]

I am posting this here just out of interest.

For those out there that might be interested in the solution to this old problem:
4 years later I managed to resolve it for the remaining legacy Clipper apps still being used by our clients

In summary the reason for the Clipper application runs very slowly is because XP incorrectly thinks the app is inactive and then reduces its cpu cycles.
XP thinks it is inactive because all the DBF activity is replaced with communications between the Clipper app and AdsDosIp on the same pc, which comms XP does not "see" / recognise as activity.
The solution is to change your Clipper app so that XP correctly recognises it as being active when it is active, via dummy local dbf activity

Below is the explanation in our application help file
Advantage Server - Enhancements to speed up the module when using Advantage server

· The XP operating system reduces CPU cycles allocated to 16 bit DOS applications when it determines them to be inactive.

· When the Dos module is run without advantage server, it directly manipulates the dbf tables on the server, which causes XP to correctly recognize when the module is busy.

· When the Dos module is run with Advantage Server (via the 32 communications AdsDosIp.exe program), the Dos module no longer directly manipulates the dbf tables on the server [instead it communicates with the AdsDosip module on the same PC which in turn communicates with the server software], which causes XP to incorrectly determine it to be inactive, which results in XP reducing the CPU cycles for the module – the result is that the module runs slowly and sluggishly.

· Changes have been made to simulate direct dbf access (via a dummy local dbf table named AdsDosip.tmp in the temp folder) when using Advantage server via AdsDosip, so that XP correctly recognizes when the module is active.

· The result is that the module now runs much faster than previously when using Advantage Server - up to now it was significantly slower.

· The module it will now run at the same speed or faster compared to when not using Advantage Server.

· Note that Advantage server is required in big environments with lots of users, where the normal direct dbf file access method slows down significantly as user no’s grow.

· The new AdsDosIp optimisation functionality can be turned off by creating message file "NoOptAds.msg"

· All QuickTrav users using Advantage server must upgrade to this version and will benefit from a significant improvement in speed.


When running via adsdosip, the application now opens an additional local dummy dbf via COMIX/DBFCDX (not dbfcdxax) on the c: drive
Whenever any of the following **calls** (now centralised) are made, a dbskip() call is made in the dummy dbf i.e. dummy->(DbSkip())
XP 'sees' the dummy dbf activity and now correctly "sees" the application as active when it is active

**calls** DbSeek, DbSkip, DbAppend, DbGoTop, DbGoBottom DbGoto, DbEval, CopyTo, AppendFrom

Thus whenever there are dbf communications between the clipper app and adsdosip, there is now also local dummy dbf activity, which XP sees as activity
The dummy dbf has a single C1 field with 10 records in it

One test report's speed has increased from 6 minutes to 40 seconds!

Note some users had realiased that holding down a key during long reports achieved similar results to the above, but the above is a proper permanent solution and explanation.

I hope this helps others out there

Peter

[Antonio Linares]

Peter,

Thanks for sharing that info with us

[James Bott]

Peter,

Good work figuring that out! Thanks for sharing.

James