×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Foxpro database is very slow

Foxpro database is very slow

Foxpro database is very slow

(OP)
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.

RE: Foxpro database is very slow

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

RE: Foxpro database is very slow

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

RE: Foxpro database is very slow

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.

I have a very large database (30,000,000) records in 85 tables with about 245 average on-line users. It works very well.

some additional tips

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'

2). For large lookups into grids or combos or list boxes use the same syntax except substitute the dbf syntax for CURSOR.

You will find that the slowness is probably due to the screens refreshing the temporary data tables and the above will generally cure that.


RE: Foxpro database is very slow

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

RE: Foxpro database is very slow

Proton, is the application (presumably the EXE) located on the server? Your note that "screen redraws" are slow, not just data retrieval, leads me to believe that there is a lot of network traffic. I assume that when you say "screen redraws", you mean the entire form, NOT just the values within the textboxes, etc.

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.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login


Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close