Linked Server Error using MSDTC - sql

I am Showing An example of Stored Procedure For Data Transaction using "Linked Server" Between Two System Through Internet
Alter Proc [dbo].[usp_Select_TransferingDatasFromServerCheckingforExample]
#RserverName varchar(100), ----- Server Name
#RUserid Varchar(100), ----- server user id
#RPass Varchar(100), ----- Server Password
#DbName varchar(100) ----- Server database
As
Set nocount on
Set Xact_abort on
Declare #user varchar(100)
Declare #userID varchar(100)
Declare #Db Varchar(100)
Declare #Lserver varchar(100)
Select #Lserver = ##servername
Select #userID = suser_name()
select #User=user
Exec('if exists(Select 1 From [Master].[' + #user + '].[sysservers] where srvname = ''' + #RserverName + ''') begin Exec sp_droplinkedsrvlogin ''' + #RserverName + ''',''' + #userID + ''' exec sp_dropserver ''' + #RserverName + ''' end ')
set #RserverName='['+#RserverName+']'
declare #ColumnList varchar(max)
set #ColumnList = null
select #ColumnList = case when #ColumnList is not null then #ColumnList + ',' + quotename(name) else quotename(name) end from syscolumns where id = object_id('bditm') order by colid
set identity_insert Bditm on
exec ('Insert Into Bditm ('+ #ColumnList +') Select * From '+ #RserverName + '.'+ #DbName + '.'+ #user + '.Bditm')
set identity_insert Bditm off
set #RserverName=replace(replace(#RserverName,'[',''),']','')
Exec sp_droplinkedsrvlogin #RserverName,#userID
Exec sp_dropserver #RserverName
When i Running the Stored Procedure I Getting the different errors in different Time of Execution
Some time Shows this Error
"The operation could not be performed because OLE DB provider "SQLNCLI" for linked server "ServerName" was unable to begin a distributed transaction."
Another time Shows This Type of Error
OLE DB provider "SQLNCLI" for linked server "70.38.11.49" returned message "Protocol error in TDS stream".
OLE DB provider "SQLNCLI" for linked server "70.38.11.49" returned message "Communication link failure".
Msg 65535, Level 16, State 1, Line 0
Session Provider: Physical connection is not usable [xFFFFFFFF].
OLE DB provider "SQLNCLI" for linked server "70.38.11.49" returned message "Communication link failure".
Msg 65535, Level 16, State 1, Line 0
Session Provider: Physical connection is not usable [xFFFFFFFF].
OLE DB provider "SQLNCLI" for linked server "70.38.11.49" returned message "Communication link failure".
Msg 10054, Level 16, State 1, Line 0
TCP Provider: An existing connection was forcibly closed by the remote host.
I am Using the Windows Xp And SQL Server 2005 in Client side And Windows server 2003 and Sql server 2005 In Net Server
I Set the MSDTC in Both System
How Can i Solve This Problem (And also give the Correct Information For Setting The MSDTC in Windows XP And Windows server 2003)

I agree with the above posting that it might be a protocol issue but it might need to use Named Pipes as the interface.
Or it could be that the user account that the DTC service is runnning under only has local rights and no rights on the network. Use a domain account with sufficient rights on both machines to run DTC under.
Or it could be that you need to start a distributed transaction with BEGIN DISTRIBUTED TRANSACTION at the front-end of your process.

you might want to look at:
http://support.microsoft.com/kb/306212
and
http://support.microsoft.com/kb/937517

I can confirm it's a network connectivity issue. I have seen this before.
MSDTC agents must be able to connect to all database instances they are coordinating.
There was some MS-certified proceure for testing this... google for msdtc ping.

You also have to check the DNS name resolution in the IP network configuration.
For example, you have a server called server-a.mydomain.com and another one called server-b.otherdomain.com, log in the server-a and do a ping server-b (without the domain).
If it responds "Ping request could not find host server-b. Please check the name and try again." that is the problem.
Go to the Control Pannel > Network Connections > Right click in the network card > properties > Internet Protocol > Properties > Advanced > DNS > Append this DNS suffix in order. And here add the local domain: mydomain.com and then add the remote domain: otherdomain.com . Click OK until you exit
Now if you do the ping server-b it should repond something like:
Pinging server-b.otherdomain.com [192.168.1.2] with 32 bytes of data:
Reply from 192.168.1.2: bytes=32 time=12ms TTL=64
Reply from 192.168.1.2: bytes=32 time=9ms TTL=64
Now try to again to execute the distributed transaction.

A long shot, but i've encountered a similiar problem a while back, on MSSQL Server 7. It turned out that both system were required to contact each other by NetBios names, and since they were not part of a Domain (but were communicating over the WAN like in your case).
A simple solution, at least to check if this is the case, would be to edit lmhosts file to map the computer name of each one its IP address (both in the client and server).
See a somewhat confused post i made back then:
http://groups.google.com/group/microsoft.public.sqlserver.server/browse_thread/thread/2c246bd2afc7c4d9

Related

sp_send_dbmail blocks and causes PREEMPTIVE_OS_GETPROCADDRESS

I have a strange issue with msdb.dbo.sp_send_dbmailwithin a stored procedure (code simplified):
SET NOCOUNT ON;
SET XACT_ABORT ON;
-- ...
SET #msg = N'...';
SET #filename = N'...';
EXEC msdb.dbo.sp_send_dbmail
#recipients = 'mailaddr#example.com'
, #blind_copy_recipients = 'another_mailaddr#example.com'
, #from_address = 'senders_mail#example.com'
, #subject = N'...'
, #body = #msg
, #query = N'SET NOCOUNT ON; SELECT <something> FROM <a_view>;'
, #execute_query_database = N'<same database the proc resides in>'
, #query_result_width = 8000
, #attach_query_result_as_file = 1
, #query_attachment_filename = #filename
, #query_result_header = 1
, #query_result_separator = ';'
, #query_result_no_padding = 1
, #exclude_query_output = 1;
I have a database user which is member of db_datareaderand EXECUTEpermissions for the stored procedure. Furthermore the assigned server login is mapped to msdband a member of the DatabaseMailUserRole. There is only 1 single mail profile which is public and flagged as default.
Everything works fine from SSMS: connect with the user's credentials and execute the stored procedure. Great!
The first oddity: if I'm logged in as sysadmin and try to EXECUTE AS it doesn't work. Okay, I found something that points out that there are issues with this.
But the main issue is this: I call the procedure from a 3rd party Java application which connects using the jTDS driver (don't know if this is important). The applicaton executes the procedure ... and nothing else happened (no log entries, the task freezes).
In the activity monitor I see the following:
Process <...>
Database master (??? I've never connected to this
db!)
Task State Running
Wait Type PREEMPTIVE_OS_GETPROCADDRESS
Head Blocker 1
To make things worse I cannot kill this process. If I try this the Command column in the activity monitor shows only KILLED/ROLLBACK.
KILL <PROCESS-ID>shows
spid <...>: Transaction rollback in progress. Estimated rollback completion: 0% Estimated time left: 0 seconds.
I have to restart the whole instance to get rid of the process.
What is happening here?
Finally I found the answer here: blocking from xp_sysmail_format_query waittype of preemptive_os_getprocaddress
It seems that the Java application opens a transaction explicitly (there are 2 calls to stored procedures consecutively). After setting the Auto-Commit option of the database adapter to on everything work's fine.

Querying Active Directory with T-SQL

Have tried:
EXEC master.dbo.sp_addlinkedserver
#server = N'ADSI',
#srvproduct=N'Active Directory Services',
#provider=N'ADsDSOObject',
#datasrc=N'server_name.your_domain.com'
EXEC master.dbo.sp_addlinkedsrvlogin
#rmtsrvname=N'ADSI',
#useself=N'False',
#locallogin=NULL,
#rmtuser=N'your_domain\domain_user',
#rmtpassword='********'
SELECT *
FROM OPENQUERY (ADSI, 'SELECT *
FROM ''LDAP://DC=your_domain,DC=com''')
Getting this error:
Msg 7321, Level 16, State 2, Line 1
An error occurred while preparing the query "SELECT * FROM 'LDAP://DC=your_domain,DC=com'" for execution against OLE DB provider "ADsDSOObject" for linked server "ADSI".
I have already confirmed mine and the SQL Server Service domain accounts have read access to AD, and that the "Allow inprocess" is enabled on the ADsDSOObject provider is selected.
Any thoughts would be appreciated.
Every example I could find had: LDAP://DC=your_domain,DC=com as syntax. Well for our server (and maybe other's) it is: LDAP://DC=your_domain,DC=internal
As suggested by someone, I used the Softerra LDAP browser (free) and opened the server, clicked on the top node and found distinguished name entry listed as: DC=your_domain,DC=internal
Once I made that change, I could see the AD data.

Execute stored procedure, but access denied

I tried to execute a stored procedure. But I this error below, at every stance of execution:
Msg 18456, Level 14, State 1, Line 3 Login failed for user 'NT
AUTHORITY\ANONYMOUS LOGON'.
Thank you.
This is what I try to execute:
USE [Artikelen]
GO
DECLARE #return_value int
EXEC #return_value = [dbo].[BerekenSKU]
#loc = N'AM',
#lev = N'3436',
#reset = true
SELECT 'Return Value' = #return_value
GO
I am using Microsoft SQL 2014
Error shows that there is credential issue. Please check this link.
This message indicates that you are attempting to access the linked
server by using Windows NT authentication to impersonate the client
connecting. Refer Link
Look at the stored procedure in question. The login is failing at the
linked server because whoever is calling it doesn't have mapped
credentials set up.
Refer this links:
sqlcmd: Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'
http://www.sqlservercentral.com/Forums/Topic548200-146-1.aspx
http://www.sqlservercentral.com/Forums/Topic1523177-1550-1.aspx
http://www.sqlservercentral.com/Forums/Topic246883-110-1.aspx
http://www.sqlservercentral.com/Forums/Topic246883-110-1.aspx

SQL Server OLEDB error with no details

I have a SQL Server Agent job running, which uses a stored procedure to do several operations, then exports some data to an xls spreadsheet and emails that spreadsheet. Most of the time it works, but several times a month the job fails with the error:
OLE DB provider 'Microsoft.Jet.OLEDB.4.0' reported an error. The provider did not give any information about the error. [SQLSTATE 42000] (Error 7399). The step failed.
Thanks, Microsoft, for the detailed error message. Anyway, the short term fix is usually to simply re-run the job. Usually this works, but in rarer cases it does not, and I must restart the SQL Server instance.
Here is how my code interacts with OLEDB:
Insert into OPENROWSET('Microsoft.Jet.OLEDB.4.0', 'Excel 5.0;Database=\\Excel\POStatus\POStatus.xls;',
'SELECT * FROM [POStatus$]')
Select --Tons of columns with tons of math and functions
FROM --5 tables joined together (left joins)
WHERE -- Tons of where conditions
Order by --Case statement for custom sorting
Set #vCommand = 'copy \\Excel\POStatus\POStatus.xls \\Excel\POStatus\POStatus_' + #vDate + '.xls'
EXEC master..xp_cmdshell #vCommand , NO_OUTPUT
... omitted for brevity...
Set #nvSubject = ' POStatus ' + #vDate
Set #nvMessage = ' This is an automated message, please respond to the IS department, thank you '
Set #nvMessage = #nvMessage + char(13) + char(10)
Set #nvAttachments = '\\Excel\POStatus\POStatus_' + #vDate + '.xls'
Exec master..xp_sendmail
#recipients = #nvRecipients , #copy_recipients = #nvCopy_recipients ,
#subject = #nvSubject , #message = #nvMessage ,
#query = #nvQuery , #width = #iWidth , #attachments = #nvAttachments
So, what is the cause of this, and how can I prevent it?
When you call OPENROWSET, it load the DLL for OLEDB provider for Excel. These operations happens inside the SQL Server Stack memory. When a lot of call to older DLL (ActiveX/COM) are made, it's not impossible that your stack might get full. You can resolve this in 2 ways:
1) You make these operations outside a TSQL code. You can use a SSIS package for example but you have to change your code not to use OPENROWSET. You can use the DTS Wizard to do most of the job. This is my personnal recommandation !
2) You can also set SQL Server to have a bigger memory Stack by using the -g command parameter. I think 256 MB is the default and you can set it to 512. To do that you need to open the SQL Server Configuration Manager. Depending on your version, you should have a place to change the "Startup Parameters"

"Uninitialized subscription" error in replication monitor

I'm using SQL Server 2012 and trying to implement transactional replication. Im using the system stored procedures to create the publications and subscriptions. I was successful in creating these things, but when i check the replication monitor, it shows "Uninitialized subscription".
When I check the synchronization status on the subscription, i found this log
Date 6/20/2012 7:36:33 PM
Log Job History (HYDHTC0131320D-PublisherDB-PublicationOne-HYDHTC0131320D\MSS-ReplicationSubscri-7C1D7509-C8A6-4073-A901-0433A2B6D2D3)
Step ID 1
Server HYDHTC0131320D\MSSQLSERVER2
Job Name HYDHTC0131320D-PublisherDB-PublicationOne-HYDHTC0131320D\MSS-ReplicationSubscri-7C1D7509-C8A6-4073-A901-0433A2B6D2D3
Step Name Run agent.
Duration 00:07:41
Sql Severity 0
Sql Message ID 0
Operator Emailed
Operator Net sent
Operator Paged
Retries Attempted 0
Message
2012-06-20 14:14:13.986 Copyright (c) 2008 Microsoft Corporation
2012-06-20 14:14:13.986 Microsoft SQL Server Replication Agent: distrib
2012-06-20 14:14:13.986
2012-06-20 14:14:13.986 The timestamps prepended to the output lines are expressed in terms of UTC time.
2012-06-20 14:14:13.986 User-specified agent parameter values:
-Publisher HYDHTC0131320D
-PublisherDB PublisherDB
-Publication PublicationOne
-Distributor HYDHTC0131320D
-SubscriptionType 2
-Subscriber HYDHTC0131320D\MSSQLSERVER2
-SubscriberSecurityMode 1
-SubscriberDB ReplicationSubscriberDB
-Continuous
-XJOBID 0xDFE51AEC7F9E3F42A450CE8874B662CD
-XJOBNAME HYDHTC0131320D-PublisherDB-PublicationOne-HYDHTC0131320D\MSS-ReplicationSubscri-7C1D7509-C8A6-4073-A901-0433A2B6D2D3
-XSTEPID 1
-XSUBSYSTEM Distribution
-XSERVER HYDHTC0131320D\MSSQLSERVER2
-XCMDLINE 0
-XCancelEventHandle 000005F8
-XParentProcessHandle 00000560
2012-06-20 14:14:13.986 Startup Delay: 619 (msecs)
2012-06-20 14:14:14.606 Connecting to Subscriber 'HYDHTC0131320D\MSSQLSERVER2'
2012-06-20 14:14:14.656 Connecting to Distributor 'HYDHTC0131320D'
2012-06-20 14:14:14.671 Parameter values obtained from agent profile:
-bcpbatchsize 2147473647
-commitbatchsize 100
-commitbatchthreshold 1000
-historyverboselevel 1
-keepalivemessageinterval 300
-logintimeout 15
-maxbcpthreads 1
-maxdeliveredtransactions 0
-pollinginterval 5000
-querytimeout 1800
-skiperrors
-transactionsperhistory 100
2012-06-20 14:14:14.683 Agent message code 21040. Publication '' does not exist.
How do I solve this issue?
I received the same error. My fix was to explicitly define the Job_login and job_password which I had as null to start with.
EXEC sp_addpullsubscription_agent
#publisher = #publisher,
#publisher_db = #publicationDB,
#publication = #publication,
#distributor = #publisher,
#job_login = $(Login),
#job_password = $(Password);
It seems there is an error in your replication setup scripts.
I suspect the error is in the call to sp_addpushsubscription_agent (if it is push subscription) or sp_addpullsubscription_agent (if it is pull subscription). Specifically the #publication parameter is wrong as the Distribution Agent is stating that the specified Publication " does not exist.
Please review your script and try again.
I faced same problem and fixed by doing the following :
-Subscriber Job owner is same as Publication User
-Subscriber User has been added to the subscriber users list and added
to the sysadmin server role
Just a few notes as I managed to get a pull subscriber up and running with a backup initialisation:
Make sure you have the agent account of the publisher, distributor and subscriber as sysadmin logins across all instances, example subscriber must be on the distributor and publisher.
Create linked servers for all components on each instance, example distributor and publisher on the subscriber.
Then take a full backup of the source database and restore without recovery on the subscription instance.
Create the publication component on the publisher database (sp_addsubscription) and make sure you have #sync_type = N'replication support only'.
Then take a diff backup of the source database and restore with recovery on the subscription instance.
Then create the pull subscription on the subscription instance (sp_addpullsubscription), note that if the source is a mirrored instance, use the original instance value here (#publisher). If you the principal on the "mirror" instance, meta data will be created correct and the distributor contains the logic to connect the log reader to either of the mirror instances.
Now you will have a problem with primary keys etc failing as the distributor started capturing data before the differential backup ... no problem. Stop the subscriber job and then add a new profile to the distributor agent with setting the -SkipErrors parameter to "2601:2627". This will skip all primary key violation transactions and continue processing. Remember to select this agent profile then and hit "OK".
Restart the subscription job and monitor the subscription as it start to catch up on the transactions.
When caught up, stop the job, change the agent profile back to the default and restart the job.
Hope this help anyone still struggling with pull subscribers based on backup initialisation ... note that at no point did I use any backup configurations within the replication configuration. Also stated that the pull subscription must not initialise (#immediate_sync = 0).
Here is the scripts:
-----------------BEGIN: Script to be run at Publisher 'DB001\OLTP'-----------------
use [DB1]
go
exec sp_addsubscription #publication = N'DB1', #subscriber = N'DB002\OLTP', #destination_db = N'DB1', #sync_type = N'replication support only', #subscription_type = N'pull', #update_mode = N'read only'
GO
-----------------END: Script to be run at Publisher 'DB001\OLTP'-----------------
-----------------BEGIN: Script to be run at Subscriber 'DB002\OLTP'-----------------
use [DB1]
exec sp_addpullsubscription #publisher = N'DB001\OLTP', #publication = N'DB1', #publisher_db = N'DB1', #independent_agent = N'True', #subscription_type = N'pull', #description = N'', #update_mode = N'read only', #immediate_sync = 0
exec sp_addpullsubscription_agent #publisher = N'DB001\OLTP', #publisher_db = N'DB1', #publication = N'DB1', #distributor = N'DB003\DIST', #distributor_security_mode = 1, #distributor_login = N'', #distributor_password = null, #enabled_for_syncmgr = N'False', #frequency_type = 64, #frequency_interval = 0, #frequency_relative_interval = 0, #frequency_recurrence_factor = 0, #frequency_subday = 0, #frequency_subday_interval = 0, #active_start_time_of_day = 0, #active_end_time_of_day = 235959, #active_start_date = 20170327, #active_end_date = 99991231, #alt_snapshot_folder = N'\\DB001\Replication', #working_directory = N'', #use_ftp = N'False', #job_login = null, #job_password = null, #publication_type = 0
GO
-----------------END: Script to be run at Subscriber 'DB002\OLTP'-----------------