|
View previous topic :: View next topic
|
| Author |
Message |
mlp
New User
Joined: 23 Sep 2005
Posts: 91
|
|
|
|
I have requirement in which I need to fill in data to one DB2 table automaticaly as and when another DB2 table has one row inserted.
Can I put some kind of rule or constraint in the create table query so that this requirement can be realised? |
|
| Back to top |
|
 |
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
search and read the db2 docs about TRIGGERS
from somewhere in the manuals
| Quote: |
| "a set of actions that are activated or triggered by an update operation on a specified base table." |
|
|
| Back to top |
|
|
mlp
New User
Joined: 23 Sep 2005
Posts: 91
|
|
|
|
| I dont want implement it via stored proc or triggers. I think it is possible in CREATE TABLE query itslef. Please correct me if I am wrong. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
| Quote: |
| I have requirement in which I need to fill in data to one DB2 table automaticaly as and when another DB2 table has one row inserted. |
| Quote: |
| I dont want implement it via stored proc or triggers. |
... typical forgotten requirement , to be satisfied without changing anything
and refusing to use the obvious solution TRIGGERS |
|
| Back to top |
|
|
Kjeld
Active User
Joined: 15 Dec 2009
Posts: 365
Location: Denmark
|
|
|
|
If you are handling updates from application programs only, you will have to identify all access modules with insert capability and modify these modules to update the other table as well.
If users update by creating their own SQL, the only way is user information and/or frequent use of an integrity check application. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| I dont want implement it via stored proc or triggers |
Suggest that what you want not be the driving force with this. . .
How might you justify not using a feature that was implemented in the database software for exactly what you need to accomplish. . .?
What business reason would prevent this? Sorry, but a developer's want is not a business reason. |
|
| Back to top |
|
|
Craq Giegerich
Senior Member
Joined: 19 May 2007
Posts: 1512
Location: Virginia, USA
|
|
|
|
| Adding a TRIGGER to the table or changing the application code would require that someone admit the design was flawed. Maybe someone could find a ways to pass this off as a user required design change. |
|
| Back to top |
|
|
Kjeld
Active User
Joined: 15 Dec 2009
Posts: 365
Location: Denmark
|
|
|
|
| Quote: |
| How might you justify not using a feature that was implemented in the database software for exactly what you need to accomplish. . .? |
The internal IT policies and standards may specify that DB2 triggers/stored procedures are not to be used in applications, to limit the number of ways update transactions enters the system, or to simplify the architecture.
Such policy decisions have a way of prevailing if no one challenges them at a later maturity state of the techniques. |
|
| Back to top |
|
|
mlp
New User
Joined: 23 Sep 2005
Posts: 91
|
|
|
|
I was trying find out a way with which I can avoid strored procs or triggers. But I guess its not possible with DB2.
I have to settle down with triggers only.
Thanks all for your help..!! |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
| Quote: |
| But I guess its not possible with DB2. |
nor with any other dbms, oracle, postgresql, informix
that I know and worked with |
|
| Back to top |
|
|
|
|
