Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Poor performance in W2K 1

Status
Not open for further replies.

timeslice

IS-IT--Management
Sep 13, 2002
17
BR
Hi,

We have a performance problem with clipper apps running in Win2000 machines. We are using Tame already, but the app is very slow: "screen refreshes", keyboard answers and database researches (the worst...) takes a long time to acomplish, even if there is no processor or memory bottlenecks. In Win98 the answers was much more faster.
Someone knows some "tricks" to help in the improvement of clipper apps in Win2000 environments?

Thanks

Marcelo
 
There are a lot of posts suggesting that W2K server is much slower than Novell. Are you using peer-to-peer?

You say that you are using Tame, is this to cure the idle problem. I have not heard of that. If you go into Task Manager and Performance are the apps running < 5% CPU? If not then there are other idle tamers I can point you to.

What version of Clipper, Blinker etc are you using?

On peer-to-peer networks, having changed from 95/98 to W2K the main thing that I noticed was writes (with commits) were slower and reading directory information was much slower. I think this reflects the belts, braces and bicycle clips approach of NT. If it says it's written then it damm well is! The general apps themself were not noticably slower, certainly screen refresh and seek showed no practical difference.

Having moved to W2K at some sites there has been far fewer problems. By the sound of your situation things are unacceptable. Give us a little more info and I'll see what I can come up with. Ian Boys
DTE Systems Ltd
 
Last NT version that worked Ok with Clipper apps for me was NT 4.0 with maximum of SP5. Anything after that was just a killer for speed.
Using W2K with SP2 is much better than bold W2K or SP1, and maybe SP3 adds some to this, but I'm not really interested.
I've stopped developing DOS apps completely, so I'll automagically get rid of this problem...
Data entry in any form can be done just as well in Windoze, or Linux for that matter.

Ian's quest for info is what's lacking from your post, so please inform us some more, as newer versions of Blinker, and linking for 'protected mode' useually give a big upper in the performance area.

HTH
TonHu
 
The problem is that the processor runs 100% with clipper DOS programs. There is a solution using dosidle() function at the beggining of your code. You can download it at
. UNRAR it and link dosidle.obj together your program. Put dosidle() function at the begginig of your program, and be happy.

Best regards

[wink];-)
 
Dalloca,
You may be correct that it's the CPU hogging. The trouble is, I would have thought that most people would have sorted that problem by now as it has been a problem, maybe less sever with 95/98. I noticed years ago when I went from Windows 3.11, where you could assign a percentage of CPU to a background app (I had several apps running at once data capturing from analysers) to 95 that performance actually went down, CPU hogging being the problem.

Some other links that may help, OSLib <URL:and look at OL_Yield() <URL:and OL_AutoYield() <URL:
Ian Boys
DTE Systems Ltd
 
Morning Y'all, first time to site, find it most interesting.
I have been writing clipper since version 1 of Nantucket, as matter of fact, still have 5 1/4 disks. On the issue of w2000 and clipper, might I offer suggestion. Do not run your application across the network, always run it off the station.
Use batch file, run Xcopy to from server your exe, then set directory to data drive, then call from your station the exe. I have done this on all types of networks over the years with execellent results. This week I have installed W2000 on station on peer to peer . It is very responsive. BTW, the batch file allows me to update the program at any time. When the user signs on again, they get the current version.
I have used this technique for the past 15 plus years on large and small networks with excellent results.
Just as a matter of information, I converted my largest application to Window (32 bit) using Xbase++, retaining the features of Clipper. Works like a charm.
Donald Dunlap
wdunlap@bellsouth.net
 
Donald,
I've done a similar thing but possibly taking it one step on. I have an update directory off the server's main data directory that contains all databases that could be run locally. The workstations check the directory prior to entering a module of the application and copy any new or updated items locally. This means that when I open 80 odd files, 65 are local and therefore this is very quick. It also means that when the app returns to the main menu I can close all databases as I know there is no great overhead opening them again.
Ian Boys
DTE Systems Ltd
 
Great suggestions. I have been doing these app splitting techniques with MS Access\VB3-6 but never considered it for Clipper.

Thanks for posting! :)
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top