Porting Java applications from the 400 (was: SQL update/insert for a string contain " ' ")

>Your assumption is that you will *always*
>use the AS/400 for your hardware platform.
>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.

I've heard several other people mention portability in the same sentence as
SQL or Java, and I'm a bit confused (typical state of affairs!)  Unless you
own the database on the 400 AND on the "new" platform, your SQL statements
would need to be re-written, right?  Let me try an example to demonstrate
where I'm coming from.

Say I have webified my customer statement inquiry application.  It dips into
3 files: CUST, AROPEN, ARDETL.  The common key between the two files is
CUSTNO, so a typical SQL might be "select
custno,name,arinv,ardate,aramt,artax from cust,aropen where custno =? and
custno=arcust"  This'll return the open invoices.  Then I can drill down
into ARDETL to get the individual line items if desired with "select
arinv,aritem,aramt,artax from ardetl where arinv =?"  That's presuming that
I'm still dealing with my 15 year old open item A/R database, created by
somebody long ago and used by hundreds of programs on the 400.  I can't
readily make changes to these files without justifying it to management.

Now, I'm moving off to Oracle on Sun.  It's a pretty good bet that the open
A/R database there does not look like the one on my 400.  If I'm in utopia,
they have 3 tables with different names and somewhat different column names,
but all in all the concept matches the 400 implementation.  What if the
Oracle guy went nuts and made a dozen related files that I need to pick
through?  Now my simple 2 statement "get invoice header and detail" expands
into...?

Here's where my ignorance comes in.  There's some underlying logic that I
haven't mapped out here; specifically calculating the detail subtotal (qty
ordered * item amount) and adding the subtotal and the tax to come up with a
total.  That seems straightforward enough unless the new system has a
fundamentally different way of calculating the extension. The point being
that the "calculate the total" logic is dependent upon the database design
and will therefore(?) need to change to match the new SQL.  I'm ignorant
because I don't know enough Java to say if the original coding would have
built a separate class for each sub-function and then a larger class to
assemble the total.

Practically speaking, how likely is it that I can pick up my Java
application, re-do the data access classes and be ready to go?

Sorry for trying everyone's patience...
  --buck