Hi,
ad 1) Stored procedures are nothing else than programs (written in either an
HLL such as RPG(LE), Cobol(LE), C(LE), CL(LE) or SQL).
Stored procedures will be called by the SQL command CALL. Like any other
program stored procedures can access and change database data (tables,
views).
Constraints and triggers are linked with physical files/tables or views
(instead of triggers) and are fired by the database manager as soon as a
specific event or action occurs for the base table/physical file or view.
That means constraints and triggers will always act in the same way,
independent which interface was used (native I/O, interactive SQL, UpdDta,
JDBC/ODBC ...)
For more information about stored procedures, triggers and user defined
functions, there is a great Redbook:
Stored Procedures, Triggers, and User-Defined Functions on DB2 Universal
Database for iSeries
http://www.redbooks.ibm.com/abstracts/sg246503.html?Open
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
-----Ursprüngliche Nachricht-----
Von: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von James H. H. Lampert
Gesendet: Thursday, 13. May 2010 22:42
An: Midrange Systems Technical Discussion
Betreff: Speaking of stored procedures . . .
I've been asked to research two SQL issues, as time permits, over the
next day and a half. I barely know where to start on one of them, and I
haven't a clue where to start on the second.
1. I've been asked to find out all I can about how stored procedures
work on midrange systems, and what they can do. And in particular, I've
been asked how they relate to triggers and constraints. Any suggestions
would be good, before I just blindly search for "sql stored procedure"
on GOOGLE, in the DisInfoCenter, and in the Softcopy CD.
2. We are contemplating a fairly extensive redesign of our major
client-server application. We use a proprietary server and communication
protocol, and our server has exit-hooks that allow us to censor lists,
and block user actions, in order to enforce the customer's business
rules, as well as automatically propagate data into any "native system"
we're asked to tie into. There has been some talk of scrapping this
proprietary server strategy in favor of having the client access the
database through JDBC. But the question is, were we to do that, would we
be able to conveniently do everything we can currently do through exit
programs?
I'd already be doing searches myself by now, except that I need to get
that "child-server-job-killer" up and running right now. Any head-start
I can get on the research would be greatly appreciated.
--
JHHL
midrange.com
