Re: Logical File or OPNQRYF or any other way ? - Legacy

["Paul Morgan" <pmorgan@xxxxxxxxxxxxxx>]

Joe,

IMHO DB2 is and isn't a relational database.

If you access the database using RPG you're using DB2 as a flat-file system.
RPG access to the data violates many of Codd's rules (Five, Seven & Eight at
least).

Five because you're using RPG instead of SQL to access the database.  You
can't do everying with the database using RPG.  You can't create tables
using RPG.  You can with SQL.

Seven because you can't do group operations against the database with RPG.
I can't delete all records satisfying a condition as I can with SQL.  I can
only delete one record at a time.

Eight because an underlying change to the database will require changes to
RPG programs.  If the sequence of fields in a table are changed or length of
fields changed  the RPG program must be modified to deal with the database
change.  No so with SQL.  SQL doesn't care that that column is the first
column in the table.

Having said all that, if you stick strictly to SQL for all your database
access then the AS/400 database is a relational database.  Until DB2/400
prevents access to the database outside of SQL it's not strictly relational.

Can you access Oracle, MS SQL Server, MySQL without using SQL?  No - even
ODBC uses SQL for data access.  You can with DB2/400 - RPG, COBOL, C, CL
commands - not good.

Nothing in Codd's rules say relations between tables must be defined in the
database.  Codd's definition of relations is between the columns in a table.
The values in a tuple/row are related - thus the term.  To relate tables you
combine them to make other tables/sets.

Paul

-- 
Paul Morgan
Senior Programmer Analyst - Retail
J. Jill Group
100 Birch Pond Drive, PO Box 2009
Tilton, NH 03276-2009
Phone: (603) 266-2117
Fax:   (603) 266-2333

"Joe Pluta" wrote

> 1. Please define exactly what characteristic gives a file "depth", and
> how that is not supported in DB2.
>
> 2. Name a database that is relational.  Identify which of the Codd rules
> it follows that DB2/400 does not.
>
> 3. Where don't we compete?  As far as I know, DB2/400 is completely ANSI
> compliant.  Please explain where it falls short.