Imagine the following scenario:
I am using SQL Server 2005. I have a transaction that is calling, among other SQL statements, a stored procedure that also has a tran
Absolutely yes, the top level transaction will own all the data changes until it is committed or rolled back.
However I would encourage you to think carefully about the transaction model. The more such scenarios exist in your system the greater your exposure to locking issues. Also the computational expense of the procedure increases.
It's remarkable how often, when rationalising SQL, I find transactions have been implemented where they just aren't required. I encourage you (and anyone working with transactions) to think carefully about why you are using them in each context and what would happen were the transaction not implemented. Just my 2c worth!