× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Alan, I'm not sure what you're saying here that I don't already know.
Sometimes people talk about SQL the same way they talk about OO, as if
it were actually some new kind of programming, where really it's just
more of the same.

Did you know that a logical can select only certain fields from a
physical file?  And that you can update the database using such a
logical, thereby gaining what you term database independence?  You can
even have JOIN logicals on an iSeries, albeit with limitations that SQL
JOINs aren't subject to (mostly because SQL JOINs have the option of
building intermediate tables when necessary).

We've done this sort of thing for many years, but we are careful about
it, because updating only a partial record is VERY dangerous.  On
writes, you can at least see NULL values, but a partially updated record
can be a very bad thing.

There is only so much you can do with your concept of database
independence, by the way.  For example, you can create a view with a
field called ONHAND that is calculated as the sum of opening balance,
issues, receipts and adjustments, but you can never update that field.
It is read-only.  Like so much of SQL, the benefits come from querying
large sets of data, not from transaction processing.

In any case, the idea of changing the underlying tables of a database
without having to change any programs is simply silly.  Some programs
will have to change or else the changes are meaningless.  In the DB2/400
world, we simply recompile the ones that don't use the new fields and
we're done; a simple added step that really doesn't bother anyone but
the SQL folks. 

If you really wanted true database independence, you would access your
database through message-based servers, which completely hide the
database and allow you to support multiple versions of messages.  No
application layer ever knows what the name of a table or a column is.
Every database action is a message, every transaction is set of
messages.  Nothing could be simpler.

Joe



> From: Alan Campin
> 
> 
> Have to disagree with you here, Joe.
> 
> Views and Logicals files are not ways to select records. Views and
Logical
> files are logical views of the data base vs. physical views of the
data
> base.
> 
> Background:
> 
> In a file system, logical and physical views of the data are the same,
> that is you bring the whole file into every program. As far as the
program
> knows, theirs is the physical view of the data.

This is NOT a logical file on the iSeries... thus I question the rest of
the discussion.

Joe


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.