Foxpro database is very slow

[proton]

I am in charge of a third party VFP 5.0 database. At times the response is excruciatingly slow. This involves both screen redraws and data retrieval. We have a Compaq server running Win NT 4.0, 10baseT ethernet, Cabletron switches, Pentium Win95 desktop clients with various NIC cards. The developers blame the network and the Network Admin blames VFP. What monitoring tools or methods are available to begin to get a picture or what's causing the bottleneck.

 

[dawg]

When our program gets slow, we re-index the tables we are using and this often will help our productivity. Hope this can help any. Dawg

 

[CAE]

Wow Proton! Your in a tough situation. How large is the<br>
database (number of records on main table) and how many<br>
clients (computers) are on the system at one time accessing the database? Trial and error from the ground up is how<br>
I would approach the problem. Could be so many different<br>
things. Good luck to you. If I ever come across any tools<br>
I'll come back and post them up here. Those type of tools <br>
would be useful to anyone doing fox on a network. Bob

 

[MikeB]

You need to use a network capture program to see what is actually passing over the network. Refresh will cause a lot of traffic as will creating temporary files on the local drive. Also if you use grid objects, the refresh on them can be large unless you limit it.<br>
<br>
I have a very large database (30,000,000) records in 85 tables with about 245 average on-line users. It works very well.<br>
<br>
some additional tips<br>
<br>
1). to fill in combo boxes use sql query to limit the records retrieved for small tables use the syntax like 'select a,b,c from infile into cursor lookfile where a=c order by name'<br>
<br>
2). For large lookups into grids or combos or list boxes use the same syntax except substitute the dbf syntax for CURSOR.<br>
<br>
You will find that the slowness is probably due to the screens refreshing the temporary data tables and the above will generally cure that.<br>
<br>
<br>

 

[Steve Bowman]

This kind of thing is IT worst nightmare the fingers start flying and someone always gets cought in the middle, more times then not I find the problem is a combination of all the above. It the program is somewhat portable try setting up a test on a stand alone box. See if the performance drastically changes I do mean big change suttle changes in performance will not help here. The other test you could try is some simple benchmarking write a small program that will create a data base table and then populate it with say 3,000,000 records or so of random data then run some indexing, sql, ... then zap and delete the table timestamping all the above operations. Run the test local then run it across the wire maybe even from several different workstations. Keep at it you will eventually find the problem. If you can eliminate the network as part of it you have something you can put in front of the developer and vice versa. If you can't quickley put togeather the above test prg I have one I could email to you

 

[foxdev]

Proton, is the application (presumably the EXE) located on the server? Your note that &quot;screen redraws&quot; are slow, not just data retrieval, leads me to believe that there is a lot of network traffic. I assume that when you say &quot;screen redraws&quot;, you mean the entire form, NOT just the values within the textboxes, etc.<br>
<br>
Assuming my assumptions are correct, try placing your application EXE on a local machine and running it from there, and see if there there is an appreciable difference. Since (again, assuming) the runtime files are on each PC, this probably won't make a dramatic difference, but you never know without trying.<br>