>>I also wondered about the Distributed Transaction question I asked:
>>
>>>>Complicating all this is the fact that most of our other Transactions to our own databases get elevated to Distributed Transactions at some point. I'm pretty sure that this would NOT apply to the above Transaction to our customer's database, since I've made it RequiresNew, but I don't know for sure as it would be called in the middle of a distributed transaction.
>>
>>Any comments about that?
>>
>I think that happens by default when you have connections into different databses (might have been db's by different vendors).
>My first gut twitch was along Garys thinking, but tempered as I viewed TS to be used for updates mostly.
>
>My first attempt would have tried to use rowversion - and perhaps scanned audit trails,
>if deletes are not logical but physical and/or RI rules are important for the biz at hand.

The particular Transaction I'm talking about (the one with the TransactionScopeOption.RequiresNew) has no updates ... it's just a series of SELECTs. Any updates that there might be are part of the customer's app using their own transactions. I don't want to interfere with their transactions, hence my need to use IsolationLevel.ReadUncommited, since I don't care about dirty reads. My testing seems to validate my assumptions, so I think I'm going to go with that.

I've experimented a bit with the Distributed Transactions, and it seems that the RequiresNew Transaction does not get enlisted in the existing Distributed Transactions, as I hoped would be the case. So, it looks like I'm good to go with that too ... I guess I answered my own questions. <g>