🚀 go-pugleaf

> My experience with SQL is that it is very slowwwww.  

There are a number of factors involved here.  For example, when I hit
our AS/400 database from VdB with a SQL statement, performance is not
too impressive.  There's a lot of overhead, and it really shows at the
front end of the transaction.  But when I signon to the AS/400 and run
its own interactive SQL facility, it's dynamite.  I mean it's zoomin'. 
Why the huge difference?  Middleware.  Between the native AS/400
database and my VdB app is the QCMN subsystem on the /400, ODBC, the
BDE, and finally VdB.  If you have native SQL drivers and can avoid
using ODBC you'll get the benefit of optimized connections and
performance.  

So some folks will tell of SQL back ends that perform very well, while
others will tell a very different story.  At my day job, I have no
choice; our data lives on an AS/400 and is likely to stay there for a
while, so I do things to speed up my access where performance is a
concern.

There are a few things I just love local SQL for.  We do lots of
counting across our data; frequency distributions and the like.  With
SQL I can get an answer set in a jiffy with something like:
  
   select dlrno,count(dlrno) from :as400:fuss.tdauto where eventcode =
'TGCD'

In dBASE DML or with an AS/400 query it would have taken several steps
to get the simple report I needed.

kgc