Yeah, I moved it out of the transaction.

It seems like an arbitrary decision - if, in fact, it was a conscious decision - to exclude this from a transaciton. Because most of .NET seems very well thought out, I believe this one was missed by QA. It makes more sense to accept a connection string/connection object and procedure name as the parameters to DeriveParameters instead of a SqlCommand if the true intention is to exclude the call from a transaction.

The documentation doesn't mention anything about working with a transaction, and SqlException is not listed as a possible exception. I think this one is a bona-fide bug.

>Keith,
>
>I've been out of town, or I would've replied sooner. In addition to Cathi's suggestion (to do the DeriveParameters prior to starting the transaction), another option is to do the DeriveParameters under it's own connection. This is the way I did my workaround when I ran into this, because doing it prior to starting the transaction was not feasible in the scenario I was working under.
>
>Don't feel bad, I pulled my hair out for awhile myself trying to find a workaround. I'm assuming you found a workaround yourself, as you don't seem to be asking a question, just pointing out the problem ...
>
>~~Bonnie
>
>
>
>>It seems that SqlCommandBuilder.DeriveParameters will not participate in a transaction when the SqlCommand that it uses has a transaction assigned to it.
>>
>>This can be a real PITA to track down when combined with the Data Application Block's parameter caching. I pulled my hair out for two days isolating this sucker.