Re: Wrongly using embedded SQL

<snip>
I also personally hate the
database independence argument, I like the DB2 data base as deployed to
the iSeries servers. I don't care about independence, My RPG program is
not going to be run on another system.
</snip>

Ok, you are losing me. What does having to recompile every program in a
system to change a table have to do with using the data off the system?

I just spent an hour in a meeting talking about trying to get around a
lack of database independence. Instead of just being able to change a
table to add a new field which I could do in almost any other system, we
are trying to figure out what other field we can use or create an
auxiliary table to hold the other data and program to update it and
program to use it, on and on. Multiply that by 10 of thousands of shops
over the years and the costs are staggering. All because I do not have
database independence.

I have worked on SQL Server system. I need a new field. Add it and I
don't have to touch anything.

Maybe you not understanding what database independence means?

<snip>
There are times when using SQL
makes sense, but to say never use native IO is wrong in my opinion.
</snip>

Nowhere do I say to never use Native I/O. What I said was to always use
SQL if you can. Only drop back into Native I/O if you have too.

There are times when I have to use Native I/O. I simply don't have any
choice but I find those times being fewer and fewer, especially as IBM
makes SQL better and better.

Performance used to be a big problem but that has all but disappeared.

I think the other issues that I have not talked about is using SQL means
you are thinking in database. Working in files means you thinking about
files not database. The more I can think in database, the better off I
am going to be. Another way to say this is that the sooner we start to
use the AS/400 as a database machine instead of a glorified S/36 file
system, the better off we are going to be.

Use SQL as first choice, file I/O only if forced back into it.