Michael Dinsmore wrote:
> Well, if you use stored procs then you get better performance with MS
> SQL. You also get the ability to change the stored proc without having to
> modify source code, as long as the input parameters stay constant.
> Some other DBs don't support stored procedures, so you have to weigh that
> against it... but its always easy enough to put the SQL into the code later
> if thats what you decide to do.
> Basically, I say there is no reason why you shouldn't use stored procs if
> you're using SQL, even if you think you might be moving to Oracle or
> something a couple years down the road.
> Anyone know any major reason why its bad that I missed?
>
One portability issue to watch out for, even if you might contemplate migrating
between two databases that both support stored procedures, is that returning a
result set from a stored procedure is not standardized. This is a very handy
thing to have (because you can encapsulate the search criteria and any
necessary joins inside the procedure) -- but the JDBC standard
CallableStatement only lets you define a scalar return value.
Oracle's JDBC driver, for example, lets you return a cursor that you can
convert into a JDBC result set, but you have to use the Oracle-specific
features of their driver to do it. If you encapsulate this carefully, though,
you can minimize the portability impact.
Craig McClanahan
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
