• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 455
  • Last Modified:

DTS gives error message

Hi:

Updating the tables using DTS packages…
Connection to the database for task “XXX _update”  does not support joining distributed transactions or failed when attempting to join. Unable to enlist the transaction
New transaction cannot enlist in the specified transaction coordinator

I have DTS running.
Database are in different servers
DTS uses simple update sql statments
Can anybody help me?

Thanks,
sripri96
0
sripri96
Asked:
sripri96
  • 6
  • 5
1 Solution
 
obahatCommented:
The problem is probably with the distributed transaction coordinator (DTC). The machine from which the data is coming from cannot see the machine to which you are transferring the data.

To remedy this:
Open up your hosts file
C:\WINNT\system32\drivers\etc\hosts
and add an entry into it that contains the name and IP of the target machine (i.e., the machine to which the data is sent).
Save the file, and try again.

These issues typically arise when the DNS entries in the domain that contains your database are not up to date, or some entries are missing.

Hope this helps,

Omri.
0
 
sripri96Author Commented:
Hi:

Thanks for the quick reponse. I did make changes to the hosts but got the same error message. Do I need to reboot and try running the DTS packages?

sripri96
0
 
obahatCommented:
No. That should do it. Try to update the hosts file on both machines, and then do it.
Also - update the hosts file on both machines with the name and IP details of the machine at which you are managing the DTS (i.e., where Enterprise Manager is installed).

It can get a little tricky, based on your network domain configurations.
Do you have multiple domains? firewalls? Make sure that the adresses are correct by pinging (i.e., ping <MachineName>) or running telnet on port 1433 (i.e., telnet <MachineName> 1433) from all machines, to all machines involved in the distributed transaction.
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
sripri96Author Commented:
I did ping the server and was able to do successfully. the other problem is when this job is run by job management tool, it runs fine but when we try to run from our machine it gives problem. we do have multiple domains and firewalls too.

0
 
obahatCommented:
The key here is to understand which addresses and machine names are visible by the machines that send/receive the DTS data. Lets denote by SExp and SImp the server that exports, and the server that imports the data, respectively.

It is possible that the machine that is running the job management tool is visible in the DNS server used by SInp and SExp, however the machine that you are running the DTS on (manually) is not.
Make sure that the addresses specified within each domain are the external addresses (i.e., you must be able to ping, or more correctly telnet over port 1433) from within the DB domain, to the machine that runs the Enterprise Manager used in the DTS process.

Please make sure that all machines can telnet and ping, using machine names (and not IPs!!!), and that all hosts files are updated for locally on all machines for which the telnet/ping is not successful.

There are several differences between the DTS and the job management tool:
DTS involves a 3rd machine that run the management of the DTS (i.e., I assume that in your setup, the box you are using Enterprise Manager to perform the DTS is neither SImp or SExp). This 3rd machine has to be properly defined in the DNS/hosts file, and must be visible from the SImp and SExp machines.
When you use the job management tool - The 3rd machine may not play any role in the DTS communication, therefore by the fact that SImp and SExp can resolve the IP of the job management machine, the DTS task will work fine, in spite of the fact that it does not work with the DTS in Enterprise Manager.

Please check all ping/telnet using machine names and not IP addresses, populate the hosts file on all the boxes for which the ping/telnet does not work, and post the outcome of the process.

We'll figure it out... just may take a little time :)
0
 
sripri96Author Commented:
thanks a lot for the detailed information. So, does that mean that the each machine(box with Enterprise Manager) that tries to talk to SImp and SExp machines have to define the DNS/hosts file. Also, i pinged using machine name and was able to do successfully. This DTS works fine when I right click the DTS package, click properties, select advanced tab and uncheck the transactions option. This way I am able to run the DTS with needed results

i will try to do other steps you have mentioned and will post the updates.

Thanks once again!

 
0
 
obahatCommented:
Comment: When the transaction is not on, then the DTC is not activated, and the reverse lookup is not needed. That's why it works in that case.
0
 
sripri96Author Commented:
i see...so, for each box(where enterprise manager exists) does the SImp and SExp machines have to define the DNS/hosts file and vice versa?

0
 
obahatCommented:
Not really. The DNS (Domain Naming System, or something like that) is part of your domain. Every domain has a DNS server that allows it to translate machine names to IP addresses and vice versa. This is part of the Intranet/network/domain.
In some cases, especially when you have multiple domains (DMZs), then:
1. Not all the machines within the domain are well defined in the DNS server. In this case, when one machine tries to look for other using its name and not its IP, then it cannot connect reliably, since it cannot translate the name to the designated address. If the machine tries to connect with the IP address and not the name - you should be fine, since no translation (i.e., DNS lookup) is needed. Computers connect using IP addresses :).
2. The more complex scenario is when machines within one DMZ try to access machines in another DMZ. In many cases the machines in the latter DMZ are not visible to the former domain (i.e., are not in the DNS server that is used by the former domain). Different internal and external IPs are used by different machines (i.e., internal IP is the one used by machines within that DMZ, where external IP is the how the machine on a different DMZ connects to that machine from another DMZ).

To overcome all such DNS issues you can:
(i) (best practice) populate entries in the DNS server for all the machines in both networks. Ask you net admin to help you with that. It's not a big deal, although needs to be done properly on the DNS server.
(ii) Not great solution (which still works fine): Populate the name and IP address entries for the machines that are not well defined in the DNS server in the hosts file. The hosts file serves as a local lookup used by each machine, much like the DNS server.

0
 
obahatCommented:
BTW - it is very simply to see whether a machine (within the same or another DMZ) is well defined in the DNS server. Simply run the following command on the command prompt:

nslookup <MachineName>

This command returns the DNS entries for that machine name, as seen in the DNS server used by the domain in which you run this command.
0
 
sripri96Author Commented:
Hi:

I am unable to test some steps as discussed earlier. Thanks for all your help Obahat! May need some more time to test the steps.

Thanks,
sripri96



0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 6
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now