Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / Component Services / April 2004

Tip: Looking for answers? Try searching our database.

distributed transaction problem

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Steve - 08 Mar 2004 20:52 GMT
Hi All,

I'm having a problem running distributed transactions from a middle tier
server to a SQL Server.  I'm getting the following error when it attempts to
connect to SQL Server inside a transaction:

[COMException (0x8004d00e): The transaction has already been implicitly or
explicitly committed or aborted]

I've researched other posts on this error and none of the resolutions seem
to help in my case.  Some additional information:

1. All servers are running Windows Server 2003.  Database server is SQL
Server 2000.

2. Servers are all standalone.  No domain involved.

3. NetBios name resolution works fine and I verified this using DTCPING.EXE

4. I've checked the "Enable Network DTC Access" when adding the application
server to Windows Server 2003 on both computers.

Any other ideas on things I may have missed?
Mark Jen [MSFT] - 09 Mar 2004 03:45 GMT
Hi Steve,

Could you give us some more details about your middle tier code? Is it a
ServicedComponent? Is it marked with a TransactionAttribute? Are you
connecting to SQL with enlist=true in the SQL Connection String or are you
using the SqlConnection.EnlistDistributedTransaction method?

Thanks,
Mark [MSFT]
--
Please reply in newsgroup.
This posting is provided "AS IS" with no warranties, and confers no rights.

> Hi All,
>
[quoted text clipped - 19 lines]
>
> Any other ideas on things I may have missed?
Steve - 09 Mar 2004 21:29 GMT
Mark,

Thanks for the reply.

Yes, the middle tier code is a ServicedComponent marked with
[Transaction(TransactionOption.RequiresNew)]

I think I found the answer to my problem in the following article:
http://support.microsoft.com/?id=827805

However, I wish I knew what holes I was opening by adding that registry key.
The KB article calls the behavior a bug but it doesn't say if a hotfix is
available.

-Steve

> Hi Steve,
>
[quoted text clipped - 35 lines]
> >
> > Any other ideas on things I may have missed?
David - 02 Apr 2004 17:41 GMT
I am having the same problem but I am not accessing the remote machine using a linked server.  I simply have an application running on a 2003 appserver trying to execute transactions against a Win 2003 db server.  Also, my registry does not even include the entry mentioned in the KB article.  Please give us an update if this is what your problem is.
Steve - 02 Apr 2004 22:18 GMT
David,

Yes, that was my situation too (no linked servers, just a middle-tier
component accessing the db server).

You have to add the key to the registry. Mine didn't exist either.

The KB article describes linked servers, but that's only one place this
problem appears.

-Steve

> I am having the same problem but I am not accessing the remote machine using a linked server.  I simply have an application running on a 2003
appserver trying to execute transactions against a Win 2003 db server.
Also, my registry does not even include the entry mentioned in the KB
article.  Please give us an update if this is what your problem is.

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.