>>> but if it's poorly written and doesn't make use of client-server best practices then traffic could be as high as native tables.
>>
>>Hmmm... I can't think of a scenario where this is true. IASM data network data access requires access to the raw table and processing queries by having to pull query data local **in addition** to producing the query result set is inevitably going to have higher bandwidth usage than just pulling C/S resultset over the wire.
>>
>>There are potential performance trade offs but in terms of memory and network usage I can't image scenarios where native Fox data access is less resource intensive. That's pretty much the entire premise behind why you'd want to use Client Server in the first place (well for FoxPro data corruption and exclusive locks in network scenarios probably rank high too).
>
>Data backup is easier, too.
>
>Back in 2006 a client purchased SAP Business One (SBO) and had it installed by a VAR. We were discussing workstation network bandwidth. The VAR claimed was originally written in Israel - in FoxPro, using native tables. He claimed that the move to a SQL Server back-end used it only as dumb storage. Even something as simple as finding a customer name pulled the full customer table over the wire to the workstation, then filtered it locally to get the result. He insisted the client set up gigabit Ethernet to all users, which was still slightly exotic at that time.
>
>In that scenario I imagine network traffic could be nearly as much as native Fox tables. I can't recall if VFP caches network data locally; if it does it's not impossible this dumb storage scenario might even be worse ;)

Yes, it was made in 1995, in Israel. Can you prove it was FoxPro? I thought it was VB!! I really need to know if it was FoxPro.