Re: Advice needed on a multimember DDS file to be converted

A SQL SELECT result set or VIEW effecting UNION ALL of the rows from several different TABLE will give effectively the same result as the DTAMBRS(*ALL) for an application that reads the data; i.e. all of the data with one VIEW name. Those so-called "real RDBMS" just are not so good as the DB2 for i5/OS which enables more features via which the task at hand can be completed. Being restricted to only one versus several ways to accomplish a task, hardly seems a worthwhile reason to investigate how the more restrictive RDBMS could be better.

Regards, Chuck

Dave Odom wrote:

Charles Wilt wrote:

On the other hand, using logicals with DTAMBRS(*ALL), you could
easily write an application that doesn't know that it's working
with a mult-membered file.

If you're working with a real RDBMS you don't need to nor want to do
such a thing. Your program or query tool just sees the ONE table
name. How the DBA set up the table for performance or availability
is not something the programmer or query person has to worry about.
Nor should they as that's one of the selling points of an RDBMS in
the first place. And, the DBA uses a CREATE TABLE (only ONE table)
statement not some other non-relational construct. In the real
RDBMS world, programmers and query writers have long since not had to
worry about table construction or access methods. I know the i5
world says you don't have to but I sure see a lot of questions on
here about "file like" access methods.

I so wish die-hard DB2/400 folks that think their platform is the
"bees knees" could spend some time working on those RDBMS that are
considered viable commercial RDBMs. Then they could better
understand what I'm talking about and see how DB2/400 really stacks
up.