Seems like these things always come up on Fridays!
I've been tasked with implementing transactional processing for a particularly nasty set of nested stored procedures. There's one entry-point procedure that calls 12 others, each of which does a bunch of calculations and then inserts or updates various tables. They all comprise a single business function - so if any one of them fail, all previous transactions should be rolled back.
I've toyed with the idea of using output parameters from the nested procs to return the primary key and function performed (insert or update) back to the entry-point proc. I've also considered having each nested proc return the T-SQL string which is currently execute and having the entry-point proc be the execution point for all of them inside a transaction block. Neither of these approaches seem particularly good/correct.
Ideas, anyone?
< M!ke >
I've been tasked with implementing transactional processing for a particularly nasty set of nested stored procedures. There's one entry-point procedure that calls 12 others, each of which does a bunch of calculations and then inserts or updates various tables. They all comprise a single business function - so if any one of them fail, all previous transactions should be rolled back.
I've toyed with the idea of using output parameters from the nested procs to return the primary key and function performed (insert or update) back to the entry-point proc. I've also considered having each nested proc return the T-SQL string which is currently execute and having the entry-point proc be the execution point for all of them inside a transaction block. Neither of these approaches seem particularly good/correct.
Ideas, anyone?
< M!ke >