Showing posts with label distributed. Show all posts
Showing posts with label distributed. Show all posts

Monday, March 19, 2012

Msg 7391 and distributed transactions

Hi,
We are wondering what setting needs to be changed to get a large distributed
transaction to run.
We have a W2K3 server, upgraded from W2K with SQL2000 SP3A applied that can
run a large distributed transaction to another W2K3 server, upgraded from
W2K with SQL2000 SP3A applied. When we try the same transaction to a newly
created W2K3 server with SQL2000 SP3A applied we get the 7391 message. We
did notice a difference in a setting for MSDTC that we made the same but
this has not worked.
Is there something that we missed because the new server is not an upgraded
W2K3 server from W2K?
Thanks
Chris Wood
Alberta Department of Energy
CANADA
See "How to enable network DTC access in Windows Server 2003"
http://support.microsoft.com/default...b;en-us;817064
GertD@.SQLDev.Net
Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
Copyright SQLDev.Net 1991-2004 All rights reserved.
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:OsrpVxPvEHA.3424@.TK2MSFTNGP09.phx.gbl...
> Hi,
> We are wondering what setting needs to be changed to get a large
> distributed
> transaction to run.
> We have a W2K3 server, upgraded from W2K with SQL2000 SP3A applied that
> can
> run a large distributed transaction to another W2K3 server, upgraded from
> W2K with SQL2000 SP3A applied. When we try the same transaction to a newly
> created W2K3 server with SQL2000 SP3A applied we get the 7391 message. We
> did notice a difference in a setting for MSDTC that we made the same but
> this has not worked.
> Is there something that we missed because the new server is not an
> upgraded
> W2K3 server from W2K?
> Thanks
> Chris Wood
> Alberta Department of Energy
> CANADA
>

Msg 7391 and distributed transactions

Hi,
We are wondering what setting needs to be changed to get a large distributed
transaction to run.
We have a W2K3 server, upgraded from W2K with SQL2000 SP3A applied that can
run a large distributed transaction to another W2K3 server, upgraded from
W2K with SQL2000 SP3A applied. When we try the same transaction to a newly
created W2K3 server with SQL2000 SP3A applied we get the 7391 message. We
did notice a difference in a setting for MSDTC that we made the same but
this has not worked.
Is there something that we missed because the new server is not an upgraded
W2K3 server from W2K?
Thanks
Chris Wood
Alberta Department of Energy
CANADASee "How to enable network DTC access in Windows Server 2003"
http://support.microsoft.com/default.aspx?scid=kb;en-us;817064
GertD@.SQLDev.Net
Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
Copyright © SQLDev.Net 1991-2004 All rights reserved.
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:OsrpVxPvEHA.3424@.TK2MSFTNGP09.phx.gbl...
> Hi,
> We are wondering what setting needs to be changed to get a large
> distributed
> transaction to run.
> We have a W2K3 server, upgraded from W2K with SQL2000 SP3A applied that
> can
> run a large distributed transaction to another W2K3 server, upgraded from
> W2K with SQL2000 SP3A applied. When we try the same transaction to a newly
> created W2K3 server with SQL2000 SP3A applied we get the 7391 message. We
> did notice a difference in a setting for MSDTC that we made the same but
> this has not worked.
> Is there something that we missed because the new server is not an
> upgraded
> W2K3 server from W2K?
> Thanks
> Chris Wood
> Alberta Department of Energy
> CANADA
>

Msg 7391 and distributed transactions

Hi,
We are wondering what setting needs to be changed to get a large distributed
transaction to run.
We have a W2K3 server, upgraded from W2K with SQL2000 SP3A applied that can
run a large distributed transaction to another W2K3 server, upgraded from
W2K with SQL2000 SP3A applied. When we try the same transaction to a newly
created W2K3 server with SQL2000 SP3A applied we get the 7391 message. We
did notice a difference in a setting for MSDTC that we made the same but
this has not worked.
Is there something that we missed because the new server is not an upgraded
W2K3 server from W2K?
Thanks
Chris Wood
Alberta Department of Energy
CANADASee "How to enable network DTC access in Windows Server 2003"
http://support.microsoft.com/defaul...kb;en-us;817064
GertD@.SQLDev.Net
Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
Copyright SQLDev.Net 1991-2004 All rights reserved.
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:OsrpVxPvEHA.3424@.TK2MSFTNGP09.phx.gbl...
> Hi,
> We are wondering what setting needs to be changed to get a large
> distributed
> transaction to run.
> We have a W2K3 server, upgraded from W2K with SQL2000 SP3A applied that
> can
> run a large distributed transaction to another W2K3 server, upgraded from
> W2K with SQL2000 SP3A applied. When we try the same transaction to a newly
> created W2K3 server with SQL2000 SP3A applied we get the 7391 message. We
> did notice a difference in a setting for MSDTC that we made the same but
> this has not worked.
> Is there something that we missed because the new server is not an
> upgraded
> W2K3 server from W2K?
> Thanks
> Chris Wood
> Alberta Department of Energy
> CANADA
>

Msg 7391 / JoinTransaction returned 0x8004d00a

I'm having trouble doing distributed transactions in a stored procedure. It
boils down to this example.
This works in Query Analyzer:
--begin distributed transaction
insert into [39.80.0.26\x3].[sm].dbo.events
select * from events
where time = @.time and seq = @.seq
--commit
But it does not work in Query Analyzer when I uncomment the distributed
xaction and commit.
I get this error:
Server: Msg 7391, Level 16, State 1, Line 12
The operation could not be performed because the OLE DB provider 'SQLOLEDB'
was unable to begin a distributed transaction.
[OLE/DB provider returned message: New transaction cannot enlist in the
specified transaction coordinator. ]
OLE DB error trace [OLE/DB Provider 'SQLOLEDB'
ITransactionJoin::JoinTransaction returned 0x8004d00a].
I'm using sqlserver 8.0.818 on Win2003 server on both sides.
I tried several things to fix it, but to no avail:
@.@.servername matches the %computername% on each machine.
I enabled DTC Network Access using dcomcnfg.exe (all four options now
enabled). I then restarted DTC and sqlserver.
I verified DTC runs as NetworkService.
I even used telnet to verify the two machines can connect to each other's
port 135.
** WHAT HAVE I MISSED ? **
How do I get distributed transactions to work on these servers?
--MikeHi
have you checked out:
http://groups-beta.google.com/group...=UTF-8&oe=UTF-8
John
"Mike" wrote:

> I'm having trouble doing distributed transactions in a stored procedure.
It
> boils down to this example.
> This works in Query Analyzer:
> --begin distributed transaction
> insert into [39.80.0.26\x3].[sm].dbo.events
> select * from events
> where time = @.time and seq = @.seq
> --commit
> But it does not work in Query Analyzer when I uncomment the distributed
> xaction and commit.
> I get this error:
> Server: Msg 7391, Level 16, State 1, Line 12
> The operation could not be performed because the OLE DB provider 'SQLOLEDB
'
> was unable to begin a distributed transaction.
> [OLE/DB provider returned message: New transaction cannot enlist in the
> specified transaction coordinator. ]
> OLE DB error trace [OLE/DB Provider 'SQLOLEDB'
> ITransactionJoin::JoinTransaction returned 0x8004d00a].
> I'm using sqlserver 8.0.818 on Win2003 server on both sides.
> I tried several things to fix it, but to no avail:
> @.@.servername matches the %computername% on each machine.
> I enabled DTC Network Access using dcomcnfg.exe (all four options now
> enabled). I then restarted DTC and sqlserver.
> I verified DTC runs as NetworkService.
> I even used telnet to verify the two machines can connect to each other's
> port 135.
> ** WHAT HAVE I MISSED ? **
> How do I get distributed transactions to work on these servers?
> --Mike

Saturday, February 25, 2012

MSDTC forcing distributed transaction

We're performing the following query from a stored procedure on our
SQL Server database:
Begin Transaction
insert into local SQL Server table
select *
from OPENQUERY(DB2 Linked Server, 'select * from DB2 Table')
Commit Transaction
When this runs, SQL Server escalates it to a distributed transaction
and MSDTC manages the transaction.
The problem is that this transaction is not always successfully
committed on the DB2 side. As part of trying to figure out why, we're
trying to figure out why this is even a distributed transaction, since
the only update is occuring locally. Why does this query force a
distributed transaction? Is there some way to reconfigure it so that
a distributed transaction is not forced?
Kees VanTilburg
VanTilburg Enterprises
Hello kees,
If I learned correctly that you want to know why the following sql
statements use the distributed transaction.
Begin Transaction
insert into local SQL Server table
select * from OPENQUERY(DB2 Linked Server, 'select * from DB2 Table')
Commit Transaction
As far as I know, When you execute a distributed query while in a local
transaction. If the OLE DB data source supports the ITransactionJoin
interface, the transaction is promoted to a distributed transaction, even
if the query is a read-only query. Therefore, I am afraid there is not an
easy way to reconfigure so that a distributed transaction is not used in
this situation.
I found the following article for your reference.
274348 INF: Distributed Queries Executed Within a Trigger Enlist MSDTC
http://support.microsoft.com/?id=274348
Regards,
Michael Shao
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

MSDTC forcing distributed transaction

We're performing the following query from a stored procedure on our
SQL Server database:
Begin Transaction
insert into local SQL Server table
select *
from OPENQUERY(DB2 Linked Server, 'select * from DB2 Table')
Commit Transaction
When this runs, SQL Server escalates it to a distributed transaction
and MSDTC manages the transaction.
The problem is that this transaction is not always successfully
committed on the DB2 side. As part of trying to figure out why, we're
trying to figure out why this is even a distributed transaction, since
the only update is occuring locally. Why does this query force a
distributed transaction? Is there some way to reconfigure it so that
a distributed transaction is not forced?
Kees VanTilburg
VanTilburg EnterprisesHello kees,
If I learned correctly that you want to know why the following sql
statements use the distributed transaction.
Begin Transaction
insert into local SQL Server table
select * from OPENQUERY(DB2 Linked Server, 'select * from DB2 Table')
Commit Transaction
As far as I know, When you execute a distributed query while in a local
transaction. If the OLE DB data source supports the ITransactionJoin
interface, the transaction is promoted to a distributed transaction, even
if the query is a read-only query. Therefore, I am afraid there is not an
easy way to reconfigure so that a distributed transaction is not used in
this situation.
I found the following article for your reference.
274348 INF: Distributed Queries Executed Within a Trigger Enlist MSDTC
http://support.microsoft.com/?id=274348
Regards,
Michael Shao
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

MSDTC forcing distributed transaction

We're performing the following query from a stored procedure on our
SQL Server database:
Begin Transaction
insert into local SQL Server table
select *
from OPENQUERY(DB2 Linked Server, 'select * from DB2 Table')
Commit Transaction
When this runs, SQL Server escalates it to a distributed transaction
and MSDTC manages the transaction.
The problem is that this transaction is not always successfully
committed on the DB2 side. As part of trying to figure out why, we're
trying to figure out why this is even a distributed transaction, since
the only update is occuring locally. Why does this query force a
distributed transaction? Is there some way to reconfigure it so that
a distributed transaction is not forced?
Kees VanTilburg
VanTilburg EnterprisesHello kees,
If I learned correctly that you want to know why the following sql
statements use the distributed transaction.
Begin Transaction
insert into local SQL Server table
select * from OPENQUERY(DB2 Linked Server, 'select * from DB2 Table')
Commit Transaction
As far as I know, When you execute a distributed query while in a local
transaction. If the OLE DB data source supports the ITransactionJoin
interface, the transaction is promoted to a distributed transaction, even
if the query is a read-only query. Therefore, I am afraid there is not an
easy way to reconfigure so that a distributed transaction is not used in
this situation.
I found the following article for your reference.
274348 INF: Distributed Queries Executed Within a Trigger Enlist MSDTC
http://support.microsoft.com/?id=274348
Regards,
Michael Shao
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

MSDTC fails on Windows 2003 but security has been reset so its not that.

I am running SQL Server 2000 (clustered server) with Windows 2003. For some reason MSDTC is failing on distributed transactions. I can run code that begins and commits a transaction from query analyzer, or run a stored procedure from Query Analyzer with the same code in it and both work great, but if I call the stored procedure from a DTS job, then the job fails with the following error:

DTSStep_DTSExecuteSQLTask_1, Error = -2147217900 (80040E14) Error string: The operation could not be performed because the OLE DB provider 'MSDASQL' was unable to begin a distributed transaction. Error source: ..... Error string: OLE DB error trace [OLE/DB Provider 'MSDASQL' ITransactionJoin::JoinTransaction returned 0x8004d00a]. Error source: Microsoft OLE DB Provider for SQL Serve. The step failed.

Any help would be appreciated!Ensure MSDTC is started on the machine.
http://www.sql-server-performance.com/forum/topic.asp?TOPIC_ID=3451 for your reference.

MSDTC configuration problem

Hi.
My application needs to do distributed transaction on remote Sql server.My
application can be run from workstations(XP professional) or from SQL server
2000...
Limitations for this application are
Worksations wont be having SQL server installed.
I cannot give administrative rights on the SQL server 2000 system( i can
give administrative rights in the SQL server itself but not for the whole
server system)
I created a sample application which has a class for doing distributed
transactions which is derived from ServicedComponent. This application when
run on SQL server 2000 runs fine.It runs fine when worksation also has SQl
server.
But i tried to run this application from a worksation where SQL server is
not installed it doesnt work.Then i configured workstations MTC to point to
remote server and when i created workstaion's login on the server machine as
administrator then the application works...but if i remove the administrator
rights on the system it doesnt...I read in the article TO CONFIGURE MSDTC
needs administrative rights on the server as well as the client.But after
configuration is over i removed the administrative right and kept it as
Standard user or restricted user it doesnt work.But since Our system cannot
give administrative logins for all the clients this would not work.

> is there any other way to make this work!!
Hello,
Did you give the workstation login the appropriate permisssions in SQL
Server? Did you tried to use SQL account to login?
Thanks,
Mohamed Sharaf
MEA Developer Support Center
ITWorx on behalf Microsoft EMEA GTSC

MSDTC and Win2K3

We have Windows 2003 OS and SQL Server 2000. We are following the following
procedure, as it is an alternate of executing a distributed transaction.
Whenever we are tying to execute the following code
begin distributed transaction
SELECT COUNT(*) FROM OPENDATASOURCE('SQLOLEDB','Data Source=
serverip;UserID=username;Password=pwd' ).AACS.dbo.edbdata
commit tran
OR
begin distributed transaction
SELECT COUNT(*) FROM OPENDATASOURCE('SQLOLEDB','Data Source=
serverip;UserID=username;Password=pwd' ).MFDATA.dbo.tbl_login
rollback
In case we are trying to execute the similar code from any other server, it
works properly but in case of our test server we receive the following error
Server: Msg 7391, Level 16, State 1, Line 2
The operation could not be performed because the OLE DB provider 'SQLOLEDB'
was unable to begin a distributed transaction.
[OLE/DB provider returned message: New transaction cannot enlist in the
specified transaction coordinator. ]
We have tried using the settings given by microsoft but it did not work.Hi
Did you check out:
http://msdn.microsoft.com/library/d...ec72e00fc01.asp
and http://support.microsoft.com/kb/827805 ?
John
"Sandeep Gupta" wrote:

> We have Windows 2003 OS and SQL Server 2000. We are following the followin
g
> procedure, as it is an alternate of executing a distributed transaction.
> Whenever we are tying to execute the following code
> begin distributed transaction
> SELECT COUNT(*) FROM OPENDATASOURCE('SQLOLEDB','Data Source=
> serverip;UserID=username;Password=pwd' ).AACS.dbo.edbdata
> commit tran
> OR
> begin distributed transaction
> SELECT COUNT(*) FROM OPENDATASOURCE('SQLOLEDB','Data Source=
> serverip;UserID=username;Password=pwd' ).MFDATA.dbo.tbl_login
> rollback
>
> In case we are trying to execute the similar code from any other server, i
t
> works properly but in case of our test server we receive the following err
or
> Server: Msg 7391, Level 16, State 1, Line 2
> The operation could not be performed because the OLE DB provider 'SQLOLEDB
'
> was unable to begin a distributed transaction.
> [OLE/DB provider returned message: New transaction cannot enlist in th
e
> specified transaction coordinator. ]
> We have tried using the settings given by microsoft but it did not work.|||Hi John,
We have checked and tried the same but it is still not working.
Regards,
Sandeep Gupta.
"John Bell" wrote:
[vbcol=seagreen]
> Hi
> Did you check out:
> http://msdn.microsoft.com/library/d...ec72e00fc01.asp
> and http://support.microsoft.com/kb/827805 ?
> John
>
> "Sandeep Gupta" wrote:
>|||Hi
I assume this select statement works without the begin distributed
transaction? Are there any other messages in the SQL Server log file or
Windows event file? Have you tried creating a linked server instead?
John
"Sandeep Gupta" wrote:
[vbcol=seagreen]
> Hi John,
> We have checked and tried the same but it is still not working.
> Regards,
> Sandeep Gupta.
> "John Bell" wrote:
>|||Hi John,
We are able to link the SQL Server through linked server but we do not have
permissions to view logs and windows event file.
Regards,
Sandeep Gupta.
"John Bell" wrote:
[vbcol=seagreen]
> Hi
> I assume this select statement works without the begin distributed
> transaction? Are there any other messages in the SQL Server log file or
> Windows event file? Have you tried creating a linked server instead?
> John
> "Sandeep Gupta" wrote:
>|||Hi
Do you still get an error when using 4 part names rather than
OPENDATASOURCE? If you do not explicitly begin and end the transactions does
it work? Have you tried removing and reinstalling MSDTC?
John
"Sandeep Gupta" wrote:
[vbcol=seagreen]
> Hi John,
> We are able to link the SQL Server through linked server but we do not hav
e
> permissions to view logs and windows event file.
> Regards,
> Sandeep Gupta.
> "John Bell" wrote:
>|||We had the same issue and found this KB article:
http://support.microsoft.com/kb/873160
This one is geared toward XP & XP Tablet, but the workaround in the KB
"fixed" our Win2003 development server after sp1 was installed (this came up
AFTER we applied sp1). Specifically it was section 2 in the workaround that
allowed it to work.
"Sandeep Gupta" <SandeepGupta@.discussions.microsoft.com> wrote in message
news:A4A64974-913C-4733-A4CD-422BC74F0005@.microsoft.com...[vbcol=seagreen]
> Hi John,
> We have checked and tried the same but it is still not working.
> Regards,
> Sandeep Gupta.
> "John Bell" wrote:
>

Monday, February 20, 2012

MSDTC and Win2K3

We have Windows 2003 OS and SQL Server 2000. We are following the following
procedure, as it is an alternate of executing a distributed transaction.
Whenever we are tying to execute the following code
begin distributed transaction
SELECT COUNT(*) FROM OPENDATASOURCE('SQLOLEDB','Data Source=
serverip;UserID=username;Password=pwd' ).AACS.dbo.edbdata
commit tran
OR
begin distributed transaction
SELECT COUNT(*) FROM OPENDATASOURCE('SQLOLEDB','Data Source=
serverip;UserID=username;Password=pwd' ).MFDATA.dbo.tbl_login
rollback
In case we are trying to execute the similar code from any other server, it
works properly but in case of our test server we receive the following error
Server: Msg 7391, Level 16, State 1, Line 2
The operation could not be performed because the OLE DB provider 'SQLOLEDB'
was unable to begin a distributed transaction.
[OLE/DB provider returned message: New transaction cannot enlist in the
specified transaction coordinator. ]
We have tried using the settings given by microsoft but it did not work.
Hi
Did you check out:
http://msdn.microsoft.com/library/de...c72e00fc01.asp
and http://support.microsoft.com/kb/827805 ?
John
"Sandeep Gupta" wrote:

> We have Windows 2003 OS and SQL Server 2000. We are following the following
> procedure, as it is an alternate of executing a distributed transaction.
> Whenever we are tying to execute the following code
> begin distributed transaction
> SELECT COUNT(*) FROM OPENDATASOURCE('SQLOLEDB','Data Source=
> serverip;UserID=username;Password=pwd' ).AACS.dbo.edbdata
> commit tran
> OR
> begin distributed transaction
> SELECT COUNT(*) FROM OPENDATASOURCE('SQLOLEDB','Data Source=
> serverip;UserID=username;Password=pwd' ).MFDATA.dbo.tbl_login
> rollback
>
> In case we are trying to execute the similar code from any other server, it
> works properly but in case of our test server we receive the following error
> Server: Msg 7391, Level 16, State 1, Line 2
> The operation could not be performed because the OLE DB provider 'SQLOLEDB'
> was unable to begin a distributed transaction.
> [OLE/DB provider returned message: New transaction cannot enlist in the
> specified transaction coordinator. ]
> We have tried using the settings given by microsoft but it did not work.

MSDTC and Win2K3

We have Windows 2003 OS and SQL Server 2000. We are following the following
procedure, as it is an alternate of executing a distributed transaction.
Whenever we are tying to execute the following code
begin distributed transaction
SELECT COUNT(*) FROM OPENDATASOURCE('SQLOLEDB','Data Source= serverip;UserID=username;Password=pwd' ).AACS.dbo.edbdata
commit tran
OR
begin distributed transaction
SELECT COUNT(*) FROM OPENDATASOURCE('SQLOLEDB','Data Source= serverip;UserID=username;Password=pwd' ).MFDATA.dbo.tbl_login
rollback
In case we are trying to execute the similar code from any other server, it
works properly but in case of our test server we receive the following error
Server: Msg 7391, Level 16, State 1, Line 2
The operation could not be performed because the OLE DB provider 'SQLOLEDB'
was unable to begin a distributed transaction.
[OLE/DB provider returned message: New transaction cannot enlist in the
specified transaction coordinator. ]
We have tried using the settings given by microsoft but it did not work.Hi
Did you check out:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cossdk/html/dc45d41e-58f7-412f-834d-fec72e00fc01.asp
and http://support.microsoft.com/kb/827805 ?
John
"Sandeep Gupta" wrote:
> We have Windows 2003 OS and SQL Server 2000. We are following the following
> procedure, as it is an alternate of executing a distributed transaction.
> Whenever we are tying to execute the following code
> begin distributed transaction
> SELECT COUNT(*) FROM OPENDATASOURCE('SQLOLEDB','Data Source=> serverip;UserID=username;Password=pwd' ).AACS.dbo.edbdata
> commit tran
> OR
> begin distributed transaction
> SELECT COUNT(*) FROM OPENDATASOURCE('SQLOLEDB','Data Source=> serverip;UserID=username;Password=pwd' ).MFDATA.dbo.tbl_login
> rollback
>
> In case we are trying to execute the similar code from any other server, it
> works properly but in case of our test server we receive the following error
> Server: Msg 7391, Level 16, State 1, Line 2
> The operation could not be performed because the OLE DB provider 'SQLOLEDB'
> was unable to begin a distributed transaction.
> [OLE/DB provider returned message: New transaction cannot enlist in the
> specified transaction coordinator. ]
> We have tried using the settings given by microsoft but it did not work.|||Hi John,
We have checked and tried the same but it is still not working.
Regards,
Sandeep Gupta.
"John Bell" wrote:
> Hi
> Did you check out:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cossdk/html/dc45d41e-58f7-412f-834d-fec72e00fc01.asp
> and http://support.microsoft.com/kb/827805 ?
> John
>
> "Sandeep Gupta" wrote:
> > We have Windows 2003 OS and SQL Server 2000. We are following the following
> > procedure, as it is an alternate of executing a distributed transaction.
> > Whenever we are tying to execute the following code
> >
> > begin distributed transaction
> > SELECT COUNT(*) FROM OPENDATASOURCE('SQLOLEDB','Data Source=> > serverip;UserID=username;Password=pwd' ).AACS.dbo.edbdata
> > commit tran
> >
> > OR
> >
> > begin distributed transaction
> > SELECT COUNT(*) FROM OPENDATASOURCE('SQLOLEDB','Data Source=> > serverip;UserID=username;Password=pwd' ).MFDATA.dbo.tbl_login
> > rollback
> >
> >
> > In case we are trying to execute the similar code from any other server, it
> > works properly but in case of our test server we receive the following error
> >
> > Server: Msg 7391, Level 16, State 1, Line 2
> > The operation could not be performed because the OLE DB provider 'SQLOLEDB'
> > was unable to begin a distributed transaction.
> > [OLE/DB provider returned message: New transaction cannot enlist in the
> > specified transaction coordinator. ]
> >
> > We have tried using the settings given by microsoft but it did not work.|||Hi
I assume this select statement works without the begin distributed
transaction? Are there any other messages in the SQL Server log file or
Windows event file? Have you tried creating a linked server instead?
John
"Sandeep Gupta" wrote:
> Hi John,
> We have checked and tried the same but it is still not working.
> Regards,
> Sandeep Gupta.
> "John Bell" wrote:
> > Hi
> >
> > Did you check out:
> > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cossdk/html/dc45d41e-58f7-412f-834d-fec72e00fc01.asp
> > and http://support.microsoft.com/kb/827805 ?
> >
> > John
> >
> >
> > "Sandeep Gupta" wrote:
> >
> > > We have Windows 2003 OS and SQL Server 2000. We are following the following
> > > procedure, as it is an alternate of executing a distributed transaction.
> > > Whenever we are tying to execute the following code
> > >
> > > begin distributed transaction
> > > SELECT COUNT(*) FROM OPENDATASOURCE('SQLOLEDB','Data Source=> > > serverip;UserID=username;Password=pwd' ).AACS.dbo.edbdata
> > > commit tran
> > >
> > > OR
> > >
> > > begin distributed transaction
> > > SELECT COUNT(*) FROM OPENDATASOURCE('SQLOLEDB','Data Source=> > > serverip;UserID=username;Password=pwd' ).MFDATA.dbo.tbl_login
> > > rollback
> > >
> > >
> > > In case we are trying to execute the similar code from any other server, it
> > > works properly but in case of our test server we receive the following error
> > >
> > > Server: Msg 7391, Level 16, State 1, Line 2
> > > The operation could not be performed because the OLE DB provider 'SQLOLEDB'
> > > was unable to begin a distributed transaction.
> > > [OLE/DB provider returned message: New transaction cannot enlist in the
> > > specified transaction coordinator. ]
> > >
> > > We have tried using the settings given by microsoft but it did not work.|||Hi John,
We are able to link the SQL Server through linked server but we do not have
permissions to view logs and windows event file.
Regards,
Sandeep Gupta.
"John Bell" wrote:
> Hi
> I assume this select statement works without the begin distributed
> transaction? Are there any other messages in the SQL Server log file or
> Windows event file? Have you tried creating a linked server instead?
> John
> "Sandeep Gupta" wrote:
> > Hi John,
> >
> > We have checked and tried the same but it is still not working.
> >
> > Regards,
> > Sandeep Gupta.
> >
> > "John Bell" wrote:
> >
> > > Hi
> > >
> > > Did you check out:
> > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cossdk/html/dc45d41e-58f7-412f-834d-fec72e00fc01.asp
> > > and http://support.microsoft.com/kb/827805 ?
> > >
> > > John
> > >
> > >
> > > "Sandeep Gupta" wrote:
> > >
> > > > We have Windows 2003 OS and SQL Server 2000. We are following the following
> > > > procedure, as it is an alternate of executing a distributed transaction.
> > > > Whenever we are tying to execute the following code
> > > >
> > > > begin distributed transaction
> > > > SELECT COUNT(*) FROM OPENDATASOURCE('SQLOLEDB','Data Source=> > > > serverip;UserID=username;Password=pwd' ).AACS.dbo.edbdata
> > > > commit tran
> > > >
> > > > OR
> > > >
> > > > begin distributed transaction
> > > > SELECT COUNT(*) FROM OPENDATASOURCE('SQLOLEDB','Data Source=> > > > serverip;UserID=username;Password=pwd' ).MFDATA.dbo.tbl_login
> > > > rollback
> > > >
> > > >
> > > > In case we are trying to execute the similar code from any other server, it
> > > > works properly but in case of our test server we receive the following error
> > > >
> > > > Server: Msg 7391, Level 16, State 1, Line 2
> > > > The operation could not be performed because the OLE DB provider 'SQLOLEDB'
> > > > was unable to begin a distributed transaction.
> > > > [OLE/DB provider returned message: New transaction cannot enlist in the
> > > > specified transaction coordinator. ]
> > > >
> > > > We have tried using the settings given by microsoft but it did not work.|||Hi
Do you still get an error when using 4 part names rather than
OPENDATASOURCE? If you do not explicitly begin and end the transactions does
it work? Have you tried removing and reinstalling MSDTC?
John
"Sandeep Gupta" wrote:
> Hi John,
> We are able to link the SQL Server through linked server but we do not have
> permissions to view logs and windows event file.
> Regards,
> Sandeep Gupta.
> "John Bell" wrote:
> > Hi
> >
> > I assume this select statement works without the begin distributed
> > transaction? Are there any other messages in the SQL Server log file or
> > Windows event file? Have you tried creating a linked server instead?
> >
> > John
> >
> > "Sandeep Gupta" wrote:
> >
> > > Hi John,
> > >
> > > We have checked and tried the same but it is still not working.
> > >
> > > Regards,
> > > Sandeep Gupta.
> > >
> > > "John Bell" wrote:
> > >
> > > > Hi
> > > >
> > > > Did you check out:
> > > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cossdk/html/dc45d41e-58f7-412f-834d-fec72e00fc01.asp
> > > > and http://support.microsoft.com/kb/827805 ?
> > > >
> > > > John
> > > >
> > > >
> > > > "Sandeep Gupta" wrote:
> > > >
> > > > > We have Windows 2003 OS and SQL Server 2000. We are following the following
> > > > > procedure, as it is an alternate of executing a distributed transaction.
> > > > > Whenever we are tying to execute the following code
> > > > >
> > > > > begin distributed transaction
> > > > > SELECT COUNT(*) FROM OPENDATASOURCE('SQLOLEDB','Data Source=> > > > > serverip;UserID=username;Password=pwd' ).AACS.dbo.edbdata
> > > > > commit tran
> > > > >
> > > > > OR
> > > > >
> > > > > begin distributed transaction
> > > > > SELECT COUNT(*) FROM OPENDATASOURCE('SQLOLEDB','Data Source=> > > > > serverip;UserID=username;Password=pwd' ).MFDATA.dbo.tbl_login
> > > > > rollback
> > > > >
> > > > >
> > > > > In case we are trying to execute the similar code from any other server, it
> > > > > works properly but in case of our test server we receive the following error
> > > > >
> > > > > Server: Msg 7391, Level 16, State 1, Line 2
> > > > > The operation could not be performed because the OLE DB provider 'SQLOLEDB'
> > > > > was unable to begin a distributed transaction.
> > > > > [OLE/DB provider returned message: New transaction cannot enlist in the
> > > > > specified transaction coordinator. ]
> > > > >
> > > > > We have tried using the settings given by microsoft but it did not work.|||We had the same issue and found this KB article:
http://support.microsoft.com/kb/873160
This one is geared toward XP & XP Tablet, but the workaround in the KB
"fixed" our Win2003 development server after sp1 was installed (this came up
AFTER we applied sp1). Specifically it was section 2 in the workaround that
allowed it to work.
"Sandeep Gupta" <SandeepGupta@.discussions.microsoft.com> wrote in message
news:A4A64974-913C-4733-A4CD-422BC74F0005@.microsoft.com...
> Hi John,
> We have checked and tried the same but it is still not working.
> Regards,
> Sandeep Gupta.
> "John Bell" wrote:
>> Hi
>> Did you check out:
>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cossdk/html/dc45d41e-58f7-412f-834d-fec72e00fc01.asp
>> and http://support.microsoft.com/kb/827805 ?
>> John
>>
>> "Sandeep Gupta" wrote:
>> > We have Windows 2003 OS and SQL Server 2000. We are following the
>> > following
>> > procedure, as it is an alternate of executing a distributed
>> > transaction.
>> > Whenever we are tying to execute the following code
>> >
>> > begin distributed transaction
>> > SELECT COUNT(*) FROM OPENDATASOURCE('SQLOLEDB','Data Source=>> > serverip;UserID=username;Password=pwd' ).AACS.dbo.edbdata
>> > commit tran
>> >
>> > OR
>> >
>> > begin distributed transaction
>> > SELECT COUNT(*) FROM OPENDATASOURCE('SQLOLEDB','Data Source=>> > serverip;UserID=username;Password=pwd' ).MFDATA.dbo.tbl_login
>> > rollback
>> >
>> >
>> > In case we are trying to execute the similar code from any other
>> > server, it
>> > works properly but in case of our test server we receive the following
>> > error
>> >
>> > Server: Msg 7391, Level 16, State 1, Line 2
>> > The operation could not be performed because the OLE DB provider
>> > 'SQLOLEDB'
>> > was unable to begin a distributed transaction.
>> > [OLE/DB provider returned message: New transaction cannot enlist in the
>> > specified transaction coordinator. ]
>> >
>> > We have tried using the settings given by microsoft but it did not
>> > work.

MSDTC across different Windows versions

Hi there.
I have a MS Distributed Transaction Coordinator qestion which doesnt involve
a clustered setup at all. I know this may not technically be the correct
forum but I've solved other MSDTC issues here before so I was hoping...!
Do you know whether any problems should be anticipated with distributed
transactions if a series of linked or remote servers were set up on machines
with different operating systems? I'm about to set up a system with 2
machines on Winows2003 and one on Windows NT => I just want to know whether
it's possible to get a distributed transaction to run ok across all 3
servers...
Any info would be appreciated!
The same protocols are used; however, technically, DTC did not come around
until Win2K. For NT 4, it was Option Pack and MTS. So, there could be some
compatibility issues there.
However, the SQL Server BEGIN DISTRIBUTED TRANSACTION is the same.
Best I can say is Test, Test, Test.
Sincerely,
Anthony Thomas

"len" <len@.discussions.microsoft.com> wrote in message
news:E31BBA8A-F9CA-4BB2-B286-29B1062030B6@.microsoft.com...
> Hi there.
> I have a MS Distributed Transaction Coordinator qestion which doesnt
involve
> a clustered setup at all. I know this may not technically be the correct
> forum but I've solved other MSDTC issues here before so I was hoping...!
> Do you know whether any problems should be anticipated with distributed
> transactions if a series of linked or remote servers were set up on
machines
> with different operating systems? I'm about to set up a system with 2
> machines on Winows2003 and one on Windows NT => I just want to know
whether
> it's possible to get a distributed transaction to run ok across all 3
> servers...
> Any info would be appreciated!
>

MSDTC - standard?

Hi there.
The distributed transaction coordinator that comes with SQL Server
(MSDTC)... is this based on some sort of standard? Are there other
implementations of DTCs?
Any info would be appreciated!
LenAFAIK, DTC supports the XA interface, a protocol defining how transaction ma
nagers can communicate
with each other. I believe XA was defined by X/OPEN, but this was years ago.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"len" <len@.discussions.microsoft.com> wrote in message
news:5ED29886-51F7-4144-AEBD-FBB2408021AF@.microsoft.com...
> Hi there.
> The distributed transaction coordinator that comes with SQL Server
> (MSDTC)... is this based on some sort of standard? Are there other
> implementations of DTCs?
> Any info would be appreciated!
> Len

MSDTC - Give it a dedicated group or use Cluster Group?

Hello group,
I have been testing out SQL 2005 clusters. I noticed that putting the
"Distributed Transaction Coordinator" resource (i.e., MSDTC) in either
its own cluster resource group or in the default Cluster Group with
the quorum works. The latter would be my preference because it saves
an IP address and a disk.
Which way -- dedicated group or shared cluster group -- is the
generally accepted best practice, though?
Thank you in advance,
J Wolfgang Goerlich
Related Links:
Microsoft Article 301600, How to configure Microsoft Distributed
Transaction Coordinator on a Windows Server 2003 cluster
http://support.microsoft.com/default.aspx?scid=kb;en-us;301600
The only reason to give it its own group is performance.
If you have a high load/use for MSDTC, you should configure it in its own
group, however this will impact available drive letters, as the dedicated
group needs a disk (and IP and net-name). If you decide to give MSDTC its
own group, you must carefully design the rest of your cluster in regards to
the available drive letters.
Most applications do not have a high load on MSDTC, and therefore there is
not need for a seperate group. It is very common to place the MSDTC resource
in the Cluster Group, using the Quorum disk.
rgds,
Edwin.
<jwgoerlich@.gmail.com> wrote in message
news:1173815091.825202.19210@.j27g2000cwj.googlegro ups.com...
> Hello group,
> I have been testing out SQL 2005 clusters. I noticed that putting the
> "Distributed Transaction Coordinator" resource (i.e., MSDTC) in either
> its own cluster resource group or in the default Cluster Group with
> the quorum works. The latter would be my preference because it saves
> an IP address and a disk.
> Which way -- dedicated group or shared cluster group -- is the
> generally accepted best practice, though?
> Thank you in advance,
> J Wolfgang Goerlich
>
> Related Links:
> Microsoft Article 301600, How to configure Microsoft Distributed
> Transaction Coordinator on a Windows Server 2003 cluster
> http://support.microsoft.com/default.aspx?scid=kb;en-us;301600
>
|||Much obliged. What's a good rule of thumb to determine a high load?
Tens of transactions per second? Hundreds or more tps?
On Mar 14, 4:54 am, "Edwin vMierlo"
<EdwinvMie...@.discussions.microsoft.com> wrote:
> The only reason to give it its own group is performance.
> If you have a high load/use for MSDTC, you should configure it in its own
> group, however this will impact available drive letters, as the dedicated
> group needs a disk (and IP and net-name). If you decide to give MSDTC its
> own group, you must carefully design the rest of your cluster in regards to
> the available drive letters.
> Most applications do not have a high load on MSDTC, and therefore there is
> not need for a seperate group. It is very common to place the MSDTC resource
> in the Cluster Group, using the Quorum disk.
> rgds,
> Edwin.
|||A simple test:
Put MSDTC in the quorum group. Establish a distributed transaction with SQL
Server, even with itself using a linked server to itself. Now move the
quorum group to passive node. Try to establish another distributed
transaction.
The result is that you cannot. The reason is that when the quorum goes
offline, the SQL Server DTC handle is destroyed.
The only way to alleviate this is to give the DTC its own dedicated cluster
group.
If you only plan on running a single instance of SQL Server, and this is the
only service you will be establishing distributed transactions with, then
put the MS DTC resource inside the SQL Server group, not the quorum.
The Microsoft articles have been updated to reflect this recommendation.
Sincerely,
Anthony Thomas

<jwgoerlich@.gmail.com> wrote in message
news:1173870206.954497.204520@.e1g2000hsg.googlegro ups.com...[vbcol=seagreen]
> Much obliged. What's a good rule of thumb to determine a high load?
> Tens of transactions per second? Hundreds or more tps?
> On Mar 14, 4:54 am, "Edwin vMierlo"
> <EdwinvMie...@.discussions.microsoft.com> wrote:
own[vbcol=seagreen]
dedicated[vbcol=seagreen]
its[vbcol=seagreen]
to[vbcol=seagreen]
is[vbcol=seagreen]
resource
>
|||Alright, I think I am following your explanation. If the MSDTC is in
the quorum resource group (e.g., the Cluster Group) and that group
goes offline then any DTC transactions will fail.
Now, how would this change if the MSDTC were in its own group (e.g.,
MSDTC Resource)? When the MSDTC Resource goes offline, any
distributed transactions will also fail. I am probably missing
something here. What would this dedicated group gain us, then?
J Wolfgang Goerlich
On Mar 16, 10:39 pm, "Anthony Thomas" <ALTho...@.kc.rr.com> wrote:
> A simple test:
> Put MSDTC in the quorum group. Establish a distributed transaction with SQL
> Server, even with itself using a linked server to itself. Now move the
> quorum group to passive node. Try to establish another distributed
> transaction.
> The result is that you cannot. The reason is that when the quorum goes
> offline, the SQL Server DTC handle is destroyed.
> The only way to alleviate this is to give the DTC its own dedicated cluster
> group.
> If you only plan on running a single instance of SQL Server, and this is the
> only service you will be establishing distributed transactions with, then
> put the MS DTC resource inside the SQL Server group, not the quorum.
> The Microsoft articles have been updated to reflect this recommendation.
> Sincerely,
> Anthony Thomas

MSDTC

hi!
I got this from Microsoft Management Console when starting the MSDTC service
.
Could not start the Distributed Transaction Coordinator Service on local com
puter
Error 1067: The process terminated unexpectedly.
Can someone plz tell me wht the hell this means and how can i fix it. it doe
s not gives any other info.
thanks for any help.Which data access API are you using, ODBC?
Which resource manager (database)?
The ODBC driver exposes the XA Switch entrypoints, that is the DLL you need
to register. If you are running on a cluster you need to repeat this on
every node of the cluster.
GertD@.SQLDev.Net
Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
Copyright SQLDev.Net 1991-2004 All rights reserved.
"Chris Bellizzi" <anonymous@.discussions.microsoft.com> wrote in message
news:082101c49a54$be0956f0$a601280a@.phx.gbl...
> Hello Everyone,
> Has anyone had any experience with the following error
> message on a win2k standard edition, running on a win 2003
> server?
> "The XA Transaction Manager cannot load the requested XA
> Dll since a registry entry is required for this operation.
> Please create a string value in the registry under
> HKLM\Software\Microsoft\MSDTC\XADLL where the value name
> is the name of the dll in the format dllname.dll and the
> value is the full path of the Dll. If you are not sure
> about the name or path of your XA Dll then please check
> the documentation for your XA provider. If this machine is
> part of a cluster please note that this registry entry
> needs to be made for each node in the cluster. cwbodbc.dll"
> ANy help would be greatly appreciated.
> TIA
> Chris
>