Distributed transaction in .NET program (MS-DTC config?!?) or rather in stored procedure via linked server?

Question

We have two databases on different database servers (MS SQL Server 2008).

We need to insert data in two tables, one on each of the two database servers, and it all needs to be within a transaction, so we need a distributed transaction.

We are inserting the data from a .NET program and I think we have got two options here:

In .NET using the TransactionScope class to initiate a distributed transaction. This worked on my dev machine in a test environment, but only AFTER I set up the DTC to allow communication with the network. However the .NET app will run eventually on client machines and they might not have set up the DTC on their operating system accordingly. And they are "normal" users, no admins on their machines.

So my first question is: Can I use the TransactionScope class in .NET on computers even if the DTC isn't set up - is their a way around this programmatically via my .NET program?

If the .NET way is not an option, would it be a good idea to use a stored procedure that builds up a distributed transaction via a linked server?

Thanks all for your replies!

Answer 1

My suggestion would be to not rely on the DTC on client machines. The DTC is really useful in a controlled environment, i.e on servers, and this is quite unrelated to .NET (that would be true if you were doing native COM/ADO). Although it could work technically, it's difficult to setup in a reliable way on end-user machines, plus you don't want to deeply tie your server transaction performance to the behavior of client machine/setups.

I suggest you use the "service oriented" approach, like you propose, create a facade stored procedure that hides the distributed work from the client. In other words keep the DTC for server-to-server communications.