🚀 go-pugleaf

> Before re-writing the app for SQL (assuming it can be done in
> 5.5a/5.6), I would like some assurance that using SQL to access 
> DBF tables in a 5.5a app will actually result in a significant 
> reduction of net traffic for the same conditions. 

You sure aren't going to get it from me <g>.  While it's possible to
decrease the amount of traffic that travels over the wire by
*redesigning* the data and/or how it's accessed (which might or might
not include a Client/Server setup using SQL), it's very easy to create
just as much traffic with SQL as with the native DML. Just changing to
SQL statements isn't going to improve traffic flow at all, I'll bet.

> I don't fully understand the mechanics of SQL
> vs. normal DBF access, 

There *is* no difference insofar as traffic is concerned.  It's not a
SQL<->DML difference the network guy was talking about, it's a
traditional fileserver<->client/server difference.  In a partitioned
client/server application, the clients make data requests.  The requests
are *processed* on the server (this is hy network traffic can decrease
considerably), then shipped to the client as an answer set or SQL
cursor.

The reason you have so much network traffic with a regular file server
setup is that each of your client machines is moving all the index file
and DBF data the application uses across that wire.  In a C/S setup much
of that is kept local to the server, so network traffic decreases
accordingly.

To do a real C/S application you need to almost completely rethink and
redesign how your application (or just the server side of it)
manipulates data.  And while C/S architecture might decrease the network
load, C/S systems themselves tend to *not* be any faster in terms of
client-side performance, and in fact can be quite a bit slower,
depending on different factors.

Sometimes you can significantly improve network performance and even
client-side performance with the good ole' dBASE DML by maximizing your
use of certain mechanisms -- like SET KEY -- and never using other
mechanisms, like SET FILTER.  That means you need to look carefully at
all your QBEs.  Sometimes I'll avoid SET RELATION altogether, and have
my forms setup "relations" as needed in this way.

So I recommend thinking very hard about this before jumping on someone's
bandwagon.

kgc