Well... consider:
1) If you wish to remain database neutral, than do JDBC. If at some point
down the road, the decision is made to switch to DB2 or some other db, your
servlet code should not break.
2) If you'd rather let someone else mess with the sql, than use stored
procedures.
I do a lot of stored procedure writing in Oracle, and I do most of it in
Java. The nice thing about using stored procedures is that you can keep the
3-tier thing intact. It also allows the DB folks to control the DML access
to the schema (for better or for worse:-), that is, the servlet as client
has no permission to directly update, delete, and insert.
In short, it has to do with the chosen architecture and/or convenience
factor.
-----Original Message-----
From: Shannyn Barr [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 16, 2001 11:17 AM
To: [EMAIL PROTECTED]
Subject: JDBC within a Servlet
Does anyone have an opinion either way on which way would be best from
within a servlet?
-Using JDBC to call a stored procedure in order to update the DB (Oracle 8i)
or
-Using JDBC to directly perform the update procedure
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
