Re: SQL statements for physical and logical files

<Charles>
My only quibble is with the above statement...</Charles>

... don't know what a quibble might be, but for me the most important diffrence between DDS and DDL is, that a view could be based on a view!!! going the SQL way you could have tables and a layer of base views (create view someView as select * from someTable) and the complete view layer of your (SQL only) application is based on this view layer, you wouldn't find any relationship of your SQL application to the physical layer of your databasse.
Using the ISAM acces methods (AKA RLA) you would loose this, regardless if you are using DDS or RLA to define your database.

Simply wrong (not only of Birgittas statement) is, that it could be a good idea to define the database with DDL and use RLA to access the data. There are restrictions, so that only fools could recommend this:
- SQL views are not real accesable by RLA, as they don't have an accespath and accessing some data in a random sequence could not be a base for any application, I could think of.
- telling people, that they could use SQL indexe for RLA access seems to be a joke to me, in reality you would end up with accesspaths containing all fields of the underlaying table - a real night mare for all DBMS!!!
- another restriction for indexes is, that you can't "emulate" DDS joinfiles.
- any performance diffrences are neglectable (BTW, my experience is: ISAM access to a single record outperforms SQL - you won't get anything for nothing and there is a price for the power of SQL, payed by CPU cycles!!!)

My recommendation are very easy:
- don't mix up the world of SQL with the world of ISAM. If you want to use the power of SQL to its end use DDL for all new segments of your database and don't use RLA to these tables.
- redefining DDS table with DDL is absolutely useless, as long as you have RLA access to these tables.
- first eliminate all RLA access to a table, before recreate a DDS table with DDL

The very goal of modernization of database access is to decouple physical implementation of the database from your applications. Nathans way of a functional layer might be an approach, but the SQL way would be less effort.

D*B