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

I see how allowing both SQL, and the READ, WRITE genre allows developers 
the ability to choose what works best for the project.

There is something to be said for portability, but often I think that's 
overrated.  The people who often argue for portability often define any 
language that only runs on a proprietary legacy system such as Windows as 
portable.  Often it is seen that making an application in which the base 
code is truly portable is either tuned to only run well on one of the 
platforms, or runs lousy on them all.  I think businesses can be better 
served if the application is portable.  For example Domino runs on 
multiple platforms:  iSeries, Linux, Unix, Windows.  Do you flop the same 
code?  No.  But the application data?  Sure.

Applications that are compatible with other database engines?  Are there 
truly applications that jump around from one database engine to the next? 
For example is there an ERP package that touts that it runs well under 
Oracle, DB2, SQL Server, actively marketed to all those environments and 
actually has more customers in each other than a number barely above 
"proof of concept"?
Is there a single customer that runs this package under multiple 
databases?  Let's say someone who has a division running it under SQL 
Server, and another running it under Oracle.  But basically the same 
package?  (And not just a subset for presentation or business analysis.)

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





"Dave Odom" <Dave.Odom@xxxxxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
03/08/2005 03:49 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
<midrange-l@xxxxxxxxxxxx>
cc

Subject
RE: Logical File or OPNQRYF or any other way ? - Legacy






Rob,

You wrote:

"What 'back door' were you thinking of?"    The ability to get to
supposedly a relational database via access verbs such as READ, WRITE,
etc.   If the iSeries were truly relational, that would not be allowed. 
 

"I didn't understand the last two sentences." 

 I'm not sure which ones to which you are referring.


"Are you trying to say that any file access, outside of imbedded SQL,
is what makes it non relational?"
I'm not comfortable with the term "imbedded SQL" as that implies to me
imbedded in a program, but the simple answer is Yes, a truly relational
database must only be accessed via one language, in all cases, and in
the truly relational world, the defacto is SQL.

"And this is a bad thing?"    Yes, it violates the essence of what Codd
was saying, and what he was saying was often oriented toward what is
best for good database and application development architecture for the
near and long term.  To wit..., allowing multiple access verbs and
paths, does not conform to the rest of the truly relational world if you
want applications built that are compatible with other relational
database engines your company might need to consider and for which there
is a good supply of traditionally trained employees in relational
database and application design.   I don't know about you but business
leaders I've consulted with don't like having an environment that is not
flexible thus making things harder when it comes to M&A activity or
expansion or downsizing. 

-- 
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.