🚀 go-pugleaf

In article <19982@hydra.gatech.EDU>, jgb@prism.gatech.EDU (James G. Baker) writes:
>>I have a 10k plus line application written in clipper (summer of 87). The
>>application is running increasingly slower as the size of it grows. The 
>>application is running on a 3com network with 8 diskless workstations. The 
>>server is a 386/16 with 2 40mb 28ms hard disks. Also the application is 
>>linked using the BLINKER dynamic linker.
> 
> How is it sow?  Screen re-fresh?  DBF access?  DBF sequential (SUM, TOTAL,
> etc)?  What size is the .DBF (<1Meg <10Meg, etc).  Are your records very
> wide (many fields) or relational?  ARE there overlays (A 40MB 28ms is not
> that much for 8 workstations (how much memory each?)
> 

The application is slow for screen refresh most likely due to DBF accesses.
There are 7 databases, 2 have dbt files. 2 of the databases have between
2mb - 4mb in them with dbt files in the same range. The remaining DBF files
are all less than 1mb in size. The application does not do any sequential
(SUM ...) access. Two of the DBF files have records with approx 100 fields
in each of them. The remaining DBF files have records with 2-30 fields in them.

The application is overlayed. It is linked using the BLINKER linker. 

Since my initial request for Help I have been told by 3com that the .exe file
is overlayed across the Net (this sounds right). I have also been told by
3com that clipper is a poor performer on 3com when the number of nodes on
the Net is above 6. 3com also stated that clipper downloads the indexes
to the workstation for all database queries. 3com recommended using Gupta
SQL server and replacing all of the database access commands with Planet
software's library for Clipper SQL server access commands. 3com could offer 
no feeling for the improvement I would gain from these changes.

The workstations have 1mb of memory each. Also, we had several "out of memory"
errors prior to using the BLINKER linker.

I am tempted to use a two phased approach to this situation:
	1. Acquire a 486/25+ server with a higher speed disk.
	   <re-assess the situation>
	2. If the problem still remains go with a back-end server
	   either Gupta or Microsoft, and use clipper 5.o's
	   available or soon to be available I/O drivers to access the
	   SQL server. (I think clippers I/O driver solution would be
	   better than the Planet library because there most likely would
	   be know need to replace all current database access commands).

What do you think? Is there an easier solution?

Thanks in advance for the advice.