I have a database called IND_DB (running on SQL Server 2008 R2) which has a table called MyTable. When there is any update in MyTable, a trigger is fired. The trigger updates another table called RemoteTable located on another server (SQL Server 2008 R2) & database. The trigger calls a stored procedure located on the remote server and updates a table on the remote server.
In order to accomplish this I have created a linked server between two servers. I have set the following properties of the link server:
RPC: TRUE
RPC OUT: TRUE
I have confirmed the MSDTC is running in both server. The firewall is not blocking the transaction.
Now when the trigger is fired, following error is shown:
No Row Updated.
The data in row 1 was not committed.
Error Source: .NET SQLClient Data Provider.
Error Message: Timeout Expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
The problem is that I can execute remote stored procedure in a query analyzer but the same remote stored procedure won't run in trigger.
Related
We have MS SQL Server 2012 and MySQL 5.5, and we need to sync one table data between the two databases. So that whenever a record is inserted in the table "trainee" in MS SQL Server then it should directly copied to the table "trainee" in MySQL database.
We used the linked server, and it works fine for reading data from MySQL with the following driver:
MySQL ODBC 5.2 UNICODE Driver
And then we added a Trigger on the table in MS SQL Server with the following code:
USE [case]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER TRIGGER [dbo].[Inserttms]
ON [case].[dbo].[mdl_tms_trainee]
AFTER INSERT
AS
Insert into dbo.tms (id,u_id,trainee_number) Values ('8','8','888');
Further more, we enable the DTC in the server, set True for RPC and RPC OUT in the LInked Server, and even created aview in the local database in MS SQL Server in order to use workaround, but these all never solve the below problem.
OLE DB provider "MSDASQL" for linked server "TMSCASEU" returned message "[MySQL][ODBC 5.2(w)
Driver]Optional feature not supported".
Msg 7391, Level 16, State 2, Procedure Inserttms, Line 5
The operation could not be performed because OLE DB provider "MSDASQL" for linked server
"TMSCASEU" was unable to begin a distributed transaction.
Error I get when I run
OLE DB provider "MSDASQL" for linked server "WEBSTAGING" returned
message "[MySQL][ODBC 5.3(w) Driver]Optional feature not supported".
Msg 7391, Level 16, State 2, Procedure
trg_DeliveryPartMap_Mysql_Stockupdate, Line 32 The operation could not
be performed because OLE DB provider "MSDASQL" for linked server
"WEBSTAGING" was unable to begin a distributed transaction.
moreover select Query works fine in sql server trigger.
But when I run on Linnked server it works fine
UPDATE OpenQuery(WEBSTAGING, 'SELECT inventory, id, originalId FROM product
WHERE originalId=Xxx') SET inventory = 13
I solved it by calling stored procedure from local server of Linked Server (MySQL Server)
without using OpenQuery I used Exec (Linked server stored procedure)
and it worked
Thanks
I have a SSIS package and it was scheduled as job. I made changes in the package and try to re-deploy the package but at that time the scheduled job running. How it will effect ?
Basically you need to understand how SQL Server Agent works internally or some sort of it's logical architecture. Any SQL server agent action is get translated into a series of stored procedure calls. Actions typically result in metadata changes inside the SQL Server store. If such a change requires an immediate update of SQL Server Agent's internal data cache or a direct response from SQL Server Agent, the extended stored procedure xp_sqlagent_notify is called to place a formatted message in a shared memory object from SQL Server. SQL Server Agent continuously looks at this communication channel and processes all information placed into the shared memory object sequentially.
SQL Server Agent is a Windows service, so if your deployment was successful then agent will refer newly deployed data.
If you are familiar with SQL profiler, you can set up a trace to watch the commands that SQL Server Agent sends to SQL Server.
I have access to a SQL view on say a server called vuk030 and i wish to write and run a stored procedure on a server called vuk386. My question is how to write the sql to access the data in the view on vuk030 as it has a username and password.
the vuk030 server is sql server 2005 and the vuk386 is 2008
The best way is to set up a linked server from vuk030 to vuk386 and enabling RPC over the linked server to make it possible to run stored procedures.
Setup linked server:
http://msdn.microsoft.com/en-us/library/aa560998(v=bts.10).aspx
RPC:
http://msdn.microsoft.com/en-us/library/ms186839(v=sql.105).aspx
I have three SQL Server 2008 boxes, call them A, B & C. Servers A & B each have a linked server to server C. The linked servers use the exact same linked server setup on both A & B. Both connect to C using the exact same login information. The login has the sysadmin role assigned to it on box C. Both were configured with RPC and RPC OUT set to true. Both can perform SELECT, INSERT, UPDATE, DELETE with no problems whatsoever. C has Allow remote connections and Require distributed transactions checked.
The problem comes when I try to execute stored procedures. A->C works fine, but when I try to run from B, I get the error:
Msg 7201, Level 17, State 4, Line 1
Could not execute procedure on remote server 'C' because SQL Server is not configured for remote access. Ask your system administrator to reconfigure SQL Server to allow remote access.
I have been completely unable to figure this out. I have checked and rechecked the linked server configurations. They are identical on both A & B. I have run test after test and every one works fine from A, but B always gives the error.
When a stored procedure is executed, it runs as the security context of the user who created the stored procedure, not the user who is executing it. It is considered a security feature.
It may be that the account used to create the stored procedure on server B does not have the correct rights while the account used to create the stored procedure on server A does.
Recreating the stored procedure on B with another account may solve the problem.