This might be a far-fetched idea, but might be worth a try.

If you have sql server on the same computer as the database, you could have it update your vfp tables through odbc.

Don't know if the overhead would make it impractically slow, but I think it'd minimize network traffic.

Another option is to write your own little vfp app that sits at the same server as the database, polling a particular folder for a text file with some code snippets to do global updates, put there by the workstations as they need this type of global update. Everything would be native vfp and traffic would be kept to a minimum. Writing something like this should be quite simple.

alex

>Hey FoxFolx!
>
>I've got a question on the situation with network traffic when it comes to VFP tables. We have set up calls to a large table on a network server to utilize minimalize database calls (i.e. UPDATE pttran SET status = 1 WHERE id = 12345). However at one company in particular that really bangs on the system with many workstations, some system utilities that take 2-3 minutes on a local system are taking 30 minutes to run.
>
>My question is this: if the example above were in pure SPT to a SQL table, it would truly be minimal, but is it actually passing lots of data back and forth in VFP? I was re-reading Chuck Urwiler's VFP C/S book and he spoke of how sometimes using a remote connection in such a situation might be better. Do you folks agree?
>
>How about a stored procedure inside the VFP database? Would passing a call to that keep everything on the server?
>
>I'm baffled about how to rectify this situation. I'd love to hear those who know more than me on this subject.
>
>Anyone? Thanks a LOT in advance!
>
>-- John Kiernan