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

Buck, this is hardly ignorance.  It is instead one of the crucial points of
designing OO business applications.  The datasource concept I presented in
my previous post is the wahy to avoid that particular pitfall.  By dividing
your application into tiers - application, object and data - you effectively
separate your application from you database layout.

This technique is especially important in the case where the database is
fundamentally different.  This can even happen on a single platform, say,
during a merger.  By using a different data source for different objects,
you can actually treat them the same in your application.  Of course, you
will have to write different methods for the data sources, but you'll have
to do that at some point.  The best place to do it is in a single,
encapsulated location, rather than strung out all over your code.

Joe


> -----Original Message-----
> From: Buck Calabro
>
> 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?