It has nothing to do with your Pervasive SQL.
 
The TAS language only uses Pervasive as a communications/transport protocol.

Lynn,
It is my understanding that the TAS5 .run programs currently use the Transactional side of the Pervasive.SQL engine (Formerly known as Btrieve) for record access.    
 
From looking at some of the DBA souce code, it appears that all data file access is "a record at a time" with the .run making decissions about whether a particular record should be included or not.  No work seems to be "pushed down" to the server.
 
Because the Client machine (executing the .run) is making these decissions, the machine speed as well as the network speed have a direct impact on how quickly a given process occures.  This also means that all records (even ones that get skipped) need to be accessed and travel the network.
 
I have re-written some reports in crystal reports using ODBC access to the DBA files so that I can "push down" record selection to the Relational side of the Pervasive.SQL server.  The improvement in speed (as well as reduction in network activity) is several orders of magnitude.
 
Will the TAS6 programs be able to acces the Relational Side of the Pervasive.SQL Server?  If not, would they at least be able to use some of the newer, Enhanced Transactional functions provided by the Transactional Engine?
 
Thanks for your continued support and enhancement of DBA.
 
Kevin Damke
Spectronics Corporation
www.spectronics.com

The basic TAS 6 language communicates with the database the same way as TAS 5 which in many types of applications (order entry for example) is faster than the SQL ODBC Access.  For some reports, however, Kevin is right, ODBC can be faster.  We are looking into adding SQL Query capability to the TAS 6 engine which would allow the best of both worlds - record level access in entry programs but SQL access for reports.