There are a few pointers you could follow up.
1. You say in your subject title there is a network error. What error number and message is it? Just telling there is a network error is not telling what the problem is, does it?
2. I said you have to find out the bottleneck to optimize and accelerate existing code, so what you can do first is measure how long the different sections of code take.
One simple method is defining a log routine that helps you see where most of the "few seconds" are spent to address that part. SECONDS() will tell you the time up to milliseconds, there are more precise methods, but I doubt you need them, STRTOFILE() is the easiest function to write a file or add a line to it aka log text, but you can also log into a dbf, just store records. And yes, this logging will of course add to the time, but you can limit that by writing to local drives, don'T log into the network drive, at start of the EXE you could copy the last session log to a central network share, empty the log file or just erase it and start over. That way you can still collect log informations over a longer period and find out which parts of dbfupdt take long, whether this only happens on specific workstations or any other pattern.
If you find out the whole time spreads evenly across all the 277 lines, then there's not much you can do, the whole time obviously depends on what saving changes actually means.
A few seconds is long when the whole change is about storing a single changed field of a single record in a single DBF. But I see the code does a lot of appending, so maybe the few seconds are quite normal for what you do in the dbfupdt method.
One thing that is typical for any system is that it starts out working fast with a small set of data, and performance degrades when the dbf files become larger. So one thought should always be is there data you can remove, at least move it into an archived section of data. AS a typical example of a shop with an order system. The essentially important orders are the ones not yet processed fully. Once an order is fulfilled data about it becomes uninteresting for order fulfillment, it only is interesting for management, statistics about prodcuct inventory or marketing research about product popularity and surely for tax, etc, but you don't need to keep every record in a main system, keeping your DBFs small accelerates a system.
Chriss
