Slow response time, large database

[samirlias]

Hi all
We have a clipper 5.2 DOS system running on 5 sites/servers. We recently modified the system to have a centralized database on Windows 2000 server, where users from 5 sites connect, run the app. on their Windows 95 workstations and access the database remotely using a network (Intranet) connection. The system became very slow after 10-15 users were using it in the same time. It takes minutes for a single hit to the database, hours to complete a simple report. The database size is 60 MegaBytes. The 2 most used tables are 20 and 8 megabytes with 150000 records in the largest.
I'm not sure is it a Clipper limitation or a network problem. May be Clipper experts/piers have hade the same problem.
Please help.

 

[Elkari]

Database operations are network I/O hogs. Even though the databases are stored on the server, it is the workstation that processes the command. This means copies of the databases must be brought to the workstation over the network in segments.
One solution is to have the server preform the operation and send just the results to the workstation. Check out is site for the product that does this. From personal experience it works extremely well.

http://www.extendedsystems.com/ADS/default.htm

 

[HotEye]

The way I have a remote user using our Clipper program is by using pcANYWHERE to dial in (56K modem) and take control of a local PC. This means that only the screen updates are transmitted to the remote station. I think pcAnywhere can be configured for network access.

If you have any PCs (old P166 OK as only running DOS app.) spare you may be able to utilise this option. The main problem is printing, this is not very good as Clipper prints to a local printer. A solution to this which I am testing is using Abee PageScript which allows you to print to a Windows printer which can be redirected to the remote workstation.

Our main database has 500000 records (214Mb) and response is OK, but not as good as local operation. Screen updates take seconds which is better than hours for database processing.

 

[oldfart]

Could be the network. Do you have switching on the hubs/routers. DOS apps don't like having the route to and from the data changed every few seconds.

If network OK then I agree with Elkari, ADS is the way to go. Works well on all servers, and simply converts your DOS app to Client Server. ADS has add-on tools: Delphi interface tool allows access to data via a browser and CGI; Web Access tool allows remote user to run the DOS app with an IP setting accessing the data over the internet.

 

[merlin511]

I contact a sale rep Concerning Advantage. There's lots of limitations concerning Filter activation in files open zone, Relations between those zone and the use of function as filter. Is there someone who can give me a real idea of the advantage limitations when runnig server and thin client on 98 workstation.

ROger

 

[oldfart]

There maybe limitations in ADS on using filters on files. However ADS uses its own index structure to get around these problems. If you're using filters and functions as filters then this is probably why your application is running slowly. Each time any record pointer moves, the Filter or Function has to be re-evaluated.
I use conditional indexes. I do not use set filter, set relation, of function within index keys.
If you can bear the pain to re-working some of your code, I still think ADS is the best network solution.