RE: SQL update/insert for a string contain " ' "

You're absolutely right, Dan.  I assume that I will be writing for the
AS/400.  Any other assumption is a poor one for my clients.

However, that's really not the issue here.  The issue is a broader one: is
SQL a valid approach when accessing AS/400 data from an OO language.  The
answer is a resounding NO!  Since he's writing in Java, he could easily
encapsulate the database access in an object.  In fact, I'm giving a class
on exactly that technique at COMMON.  Then, if for some reason you need to
access data on another database, you can attach a different data source and
your application won't know you changed.

Especially in an OO environment, it is never a valid argument to sacrifice
performance for the sake of "possible futures".  Since you can easily alter
the behavior of any class, you should always write for performance, but
encapsulate your code.

If you think about it, SQL, with all its inefficiency, was simply a first
attempt at encapsulating data access.  With true OO languages, the
requirement for this crude form of encapsulation has been removed, and so
the argument of "maybe someday moving to a different platform" is removed.
If you move to another platform, you'll have to rewrite your data access
objects, but that should be a relatively trivial procedure.  In fact, if you
want to have one version of SQL and one version of native access, you have
the best of both worlds.

If your idea of delivering quality product is to sacrifice real performance
for your user today for the sake of a possible easier conversion for
yourself sometime in the future, then I submit that perhaps your definition
of quality and mine are different.

You want the soapbox back?  <grin>

Joe


> -----Original Message-----
> From: Eyers, Daniel
>
>
> Not sure I agree with you here.  Your assumption is that you will *always*
> use the AS/400 for your hardware platform.  *and* you assume that you will
> *only* connect to AS/400s.  If I wanted to migrate my applications off the
> 400 onto some other package, I'd be hard pressed to convert the RPG and
> COBOL to some other language.  On the other hand, using the '400 as a
> development platform (and using SQL) allows me to offer systems on other
> platforms with little to no conversion.  Finally, using RPG and COBOL
> programs assumes that there is an adequate supply of COBOLers and
> RPGers.  I
> don't know about you folks but I *certainly* don't believe that to be the
> case.  In fact, the AS/400 program at the local community college
> is seeing
> significant decline in enrollment... one of the hottest classes:
> Oracle and
> SQL.
>
> Having said that, I think each shop should consider carefully the decision
> to use SQL or RPG and COBOL programs as their choice.  Performance is a
> crucial issue, however, I find I'm bound by bandwidth, not the response of
> the 400.
>
> (getting off my soapbox)
>
> dan