ISTech Support Forum
http://www.istechforum.com/YaBB.pl
Evo-ERP and DBA Classic >> Manufacturing >> SQL DBA vs. Tas5 or Tas6
http://www.istechforum.com/YaBB.pl?num=1051190931

Message started by LCFRIDAY on 04/24/03 at 07:28:51

Title: SQL DBA vs. Tas5 or Tas6
Post by LCFRIDAY on 04/24/03 at 07:28:51

Hi,
With the TAS5 and TAS6, is that totally different for the Pervasive SQL? If you are using the SQL versions now, and you use the IS Enhancements, it does not change your exsiting programming does it? We have done every well with the SQl based system. ???

Title: Re: SQL DBA vs. Tas5 or Tas6
Post by aricon on 04/24/03 at 08:35:02

It has nothing to do with your Pervasive SQL.

The TAS language only uses Pervasive as a communications/transport protocol.

Title: Re: SQL DBA vs. Tas5 or Tas6
Post by Lynn_Pantic on 04/24/03 at 09:34:16

Lorne is correct.  The standard DBA programs are written in the TAS 5 language and use the Pervasive.SQL as a database manager.  Most ISTS enhancements to date are also written in TAS 5 and are typically modifications to standard DBA programs.  Going forward with TAS 6 Evolution, we will be writing more and more programs in TAS 6 to take advantage of the Windows capabilities of the languange but the underlying database manager will still be the Pervasive.SQL you are using now.

Title: Re: SQL DBA vs. Tas5 or Tas6
Post by kevind on 04/26/03 at 19:52:51

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

Title: Re: SQL DBA vs. Tas5 or Tas6
Post by aricon on 04/27/03 at 22:36:48

Kevin,

Lynn can make a more complete comment on your questions, but having spoken to the programmers myself, I can tell you that TAS 6 unfortunately still does not use the relational component architecture in Pervasive.  Part of that is the unconventional design of the tables and table relationships.

They are not very rationalized.  Not even 1st level.  Let alone 2nd or 3rd.  A nice dream.....but not reality.

And that can cause some problems when trying to use an engine that really forces referential integrity, as you could imagine.

So, in short, no it probably isn't going to change a lot with TAS 6.

Title: Re: SQL DBA vs. Tas5 or Tas6
Post by Lynn_Pantic on 04/30/03 at 18:18:41

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.

Title: Re: SQL DBA vs. Tas5 or Tas6
Post by aricon on 04/30/03 at 22:01:42

Bravo on this one,my dear!!! :)

ISTech Support Forum » Powered by YaBB 2.1!
YaBB © 2000-2005. All Rights Reserved.