Groups | Blog | Home
all groups > sql server programming > september 2003 >

sql server programming : lots of inserts



MJ
9/2/2003 10:29:58 PM
What will be the best way to combine several inserts on
different tables?
I have a table A, when there's an insert into A, I'll
need to insert the data also into tables B, C,D,E,F,G &
H. Then based on the previpous insert, table I & K have
to be populated as well. If there's an error on this way
all the transactions (A-K) have to be rolled back. I was
making a series of nested stored procedures, fireing each
other, but may there's more inteligent solution?
I would appreciate if you could point me also some sites
I could view some similar samples...
Bhaskar Parsi
9/2/2003 11:17:36 PM
try using insert trigger on table A
and using INSERTED buffer table insert the values into
B,C,D,E,F,G.

cheers.
[quoted text, click to view]
Jacco Schalkwijk
9/3/2003 10:42:35 AM
In addition to the other posts:

The advantage of using a trigger in this case is that you don't have to
implement error handling. Any error except user defined errors and error 266
('Transaction count after EXECUTE indicates that a COMMIT or ROLLBACK
TRANSACTION statement is missing', but you're not likely to run into that)
will rollback the complete transaction, including the insert.

--
Jacco Schalkwijk MCDBA, MCSD, MCSE
Database Administrator
Eurostop Ltd.


[quoted text, click to view]

gani
9/3/2003 2:13:46 PM
create a transaction for the whole process so that you can rollback all the
changes you made
in case an error occured. try to create insert trigger for Table A that will
perform desired task for
other tables.

--
gani




[quoted text, click to view]

Joe Celko
9/4/2003 11:03:38 AM
[quoted text, click to view]
need to insert the data also into tables B, C, D, E, F, G & H. Then
based on the previous insert, table I & K have
to be populated as well. <<

The short answer is put all this work it into a single transaction.
Triggers are not portable, can be expensive and require a ton of
procedural code -- as you already can see in your nested procedures.

The fact that you have an ordering for the insertions implies that you
are writing procedural application code in SQL. Never do that; it
defeats the whole purpose of a non-procedural language.

This sounds insanely redundant -- the same data in 11 different
places!!?? If you are disassembling an input form (i.e. multiple kinds
of LOGICAL entities that come into the application in one PHYSICAL
package), do it in the front end instead.

I'd guess the RIGHT answer is to normalize the schema so that one fact
appears one way, one time and in one place. Then write your insertions.

Look up a series of articles by Tom Johnston series on redundancies that
span tables and all the problems they cause.

--CELKO--
===========================
Please post DDL, so that people do not have to guess what the keys,
constraints, Declarative Referential Integrity, datatypes, etc. in your
schema are.

*** Sent via Developersdex http://www.developersdex.com ***
AddThis Social Bookmark Button