>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

Keep in mind, anytime you deal with a VFP database/Table, ALL of your processing is done on the client machine. It doesn't matter if you are using a stored procedure or not. There is no actual server handling the requests - the client machine runs the stored procedures just like everything else. VFP has to move whatever data and indices across the wire that the stored procedure wants.

VFP can be pretty thrifty on bandwidth nonetheless as long as indices are rushmore optimized.

Using SPT to a SQL server, you really have a SQL server to process requests on the server and deliver only your result set. Network bandwidth is minimized to the extreme (assuming you aren't requesting huge data sets be returned).