If you return few records then, generally speaking, SEEK/SCAN is more economical.
As long as SQL-query is Rushmore optimized performance should be good too, but in case of joining large tables VFP will still move some extra index/data packets over the network.

>So generally it would be advisable to change queries into SEEK and SCAN in order to use less bandwidth?
>
>I am still not very sure why VFP would need so much bandwidth for a query if the returned number of data is not very huge.
>
>>You may get better network performance by using SEEK/SCAN to return 4 records.
>>
>>>One query is for example:
>>>

>>>SELECT	ti.tiKey, ;
>>>	ti.tiNumber, ;
>>>	ti.tiTickNr, ;
>>>	ti.tittKey, ;
>>>	ti.tiValue, ;
>>>	ti.tiBBOPerc, ;
>>>	ac.acDate, ;
>>>	ac.acTime, ;
>>>	ac.acCreateT, ;
>>>	ac.acMovieNam, ;
>>>	ac.acmoKey, ;
>>>	ac.acPrice, ;
>>>	ac.acTyKey, ;
>>>	ac.acRaKey, ;
>>>	ac.acThKey, ;
>>>	ac.actekey ;
>>>	FROM Tickets ti ;
>>>	LEFT OUTER JOIN ActShows ac ;
>>>		ON ti.tiackey = ac.acKey ;
>>>	WHERE ti.tiTrkey = tnBatchNr ;
>>>	INTO CURSOR cuPrint1 NOFILTER
>>>

>>>
>>>and that could return for example 4 records (if you bought four tickets)
>>>
>>>>Are you using SELECT statements for your queries?
>>>>
>>>>
>>>>
>>>>>In very simplified form:
>>>>>
>>>>>USE actshows
>>>>>=SEEK(lnCurrentShow,"ActShows","acKey")
>>>>>Select * from ActShows WHERE acDate = DATE() INTO CURSOR cuTodayShows
>>>>>
>>>>>etc.
>>>>>
>>>>>When updating records, I also do record locks where necessary.
>>>>>
>>>>>Usually updating like this:
>>>>>Insert into Tickets (tiKey, tinumber etc) VALUE (1,1, etc)
>>>>>FLUSH IN Tickets
>>>>>
>>>>>=RLOCK("ActShows")
>>>>>REPLACE acSold WITH acSold + 1 IN ActShows
>>>>>UNLOCK RECORD xx IN ActShows
>>>>>FLUSH IN ActShows
>>>>>
>>>>>There are lots of these relatively small things going on, but monitoring the network shows that the queries take most of the bandwidth, the updating much less.
>>>>>
>>>>>There are lots of smaller queries where I want to see the status of the shows, sold out shows etc, but the indexes are all there. Perhaps too many indexes?
>>>>>
>>>>>>What method are you employing to read/write to/from the vfp tables?
>>>>>>
>>>>>>
>>>>>>>Hello,
>>>>>>>
>>>>>>>We installed a ticket software on a remote location that has a 10 Mbps link to the main server. The software uses VFP tables and does some usual queries and record locks, but nothing to extravagant.
>>>>>>>
>>>>>>>However, we see that the network utilization often spikes up to 4 Mbps when doing a ticket sale for example.
>>>>>>>
>>>>>>>That causes the system to slow down dramatically when 2 or more computers are processing simultaneously.
>>>>>>>
>>>>>>>Before I am going to try to change the software to use less bandwidth, does a usage of 4Mbps sound particularly huge for VFP tables, or is this in the "normal" range of bandwidth usage? Because if I cannot hope to decrease the bandwidth to let's say only 1 Mbps maximum, I would have to consider rewriting the software to a client / server application.
>>>>>>>
>>>>>>>So I would like to know if somebody can give me some figures about what to expect. I am of course aware of the fact that it largely depends on the queries and size of data that gets transferred, but nevertheleless I do need a kind of a starting point to come to a final conclusion.