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

> Performance was only one reason for supporting SQL.  In any programming
> language, the hallmarks of good code are functionality and documentation.
> Performance is a distant 3rd (or maybe 4th and 5th).

And I submit that as Manager of Architecture at SSA, at the time the largest
AS/400 application developer in the world, the complaints I heard most often
were not about functionality or documentation, but about performance.  Pure
and simple.  Performance on MRP gens, performance on order entry,
performance on month-end close.  If rewriting month-end close in RPG saved
the end user four hours, you better believe they wanted it rewritten.  They
could care less what the code looked like.

> What I hear you saying is that in your experience, you have found that RPG
> is gives you a needed performance boost that your customers demand.  You
> have choosen a pragmatic approach that works well in your
> environment.  Fair
> enough; I'm just pointing out that your solution may not be the best
> solution is *all* cases.  Honestly, I get some pretty good
> performance from
> the JDBC driver.  I really don't see much difference between SQL and RPG.

While JDBC is adequate for queries, it doesn't perform nearly as well as RPG
in transaction processing; I've posted plenty of benchmarks to that effect
over the last year or so.  It certainly makes THE PROGRAMMER'S job faster,
but the user could care less how easy your job is, as long as it gets the
THEIR job done as quickly as possible.

> Anyway, I think we both agree that "n-tier" development is a great way to
> develop web-based systems.  I think we just differ where the lines of
> demarcation are drawn....  I value maintainability, you value performance.
> In my experience, those two attributes are usually at odds, anyway....  It
> maybe a product of my education; both my undergrad and masters are in
> business, not in computer science.....

Maintainability is an issue, but properly designed n-tier code is just as
maintainable as SQL code, and in many cases more maintainable.  There is
better visibility into file usage using native database access, and for
complex statements native code is easier to debug (although I suppose the
last is a bit of an opinion - however, I submit that 20 lines of RPG is alot
easier to read than a five-line OUTER JOIN with subselects).

Anyway, we both have opinions.  Yours is as valid as mine.  Neither of us
blathering marketing hyperbole, but sharing opinions based no our personal
experiences, so we can just agree to disagree, and implement the solution
best suited to our individual preferences.

Joe