I knew the paragraph you(TX Guru) cited, but it is a limitation that I dislike.
I am just seeking to find a way to get around of this.
Tbe need comes from this, when people write stored procedures, they often can not foresee in what context the stored procedures will be called, and it is desirable for the stored procedure to be usable both with a transactionscope environment or without
a transactionscope(i.e. standalone). If used standalone, then the sql "begin transaction/commit/rollback" construct is needed, however, if a stored proc with such a construct is used in a transactionscope environment, it might cause inconsistence as stated
in your citation.
I think there are two lines to achieve this. One is outlined in my initial post, but I am not sure if it's correct.
The other way, perhaps is to detect in stored proc if it's already in a transaction, by using soming like @@trancount, and if the function return 0, then we know we are not in a transaction. But again this approach not tested, the question is whether
@@trancount return 1 if the transaction is started by a transactionscope( System.Transaction), other than by "begin tran".