I have a table in one server and I need to update same table which is in another server, using a trigger is not a good idea because I was having issues and I read is not a good approach.
I was thinking to use either extended events or service broker, I'm using SQL Server 2014. I don't want to create a SQL Job that runs like every minute to check if table has an insert/update/delete to copy the data into the other server. Not sure which one is the best for my purpose, For example TableA on Server 1 is updated, I need to reflect this update into the other TableA on Server 2 but only when any insert/update/delete happens.
Related
I'm using SQL Server 2014, I'm wondering if there is a way to create a trigger at the server level to validate inserts on same table but in different databases.
I don't want to put this trigger directly on the database because is something that I need to check on the development environment.
For example I have a SERVER-DEV with two databases, A and B each db have a table dbo.EmployeeType, I want to make sure people working on db A don't insert EmployeeType Ids that already exists on db B and vice-versa. This is just on development environment that's why I'm looking for something extra db like the server.
I tried with CREATE TRIGGER trigger_name ON ALL SERVER but looks like there is nothing for what I want.
I want to link two SQL server instance to update clients tables if the server tables has changed (insert or update). I want the work automatically by SQL Server, I read about Linked Servers (Database Engine) in MSDN.
Does this method do what I want, or is there another way to do it?
Edit :
I want to update Data of the tables
The easiest way to do so is via a trigger on the master table like so:
use masterdatabase;
go
create trigger update_clients_of_master
on dbo.mastertable
after update as
begin
update cl1
set cl1.col1 = i1.col1, cl1.col2=i1.col2
from inserted i1
inner join clientdbname.dbo.clienttable cl1 on cl1.id=i1.id
end
If you cannot create a linked server you can use transactional replication to keep tables in sync but triggers are probably easier to maintain.
you can use Microsoft sync framework here is documentation https://msdn.microsoft.com/en-us/sync/bb887608.aspx
or use replication
You can use replication which allows you to publish one object (one table for example) or more to another server and it will automatically updates the clients table(s) when the source is changed (by insert or update).
https://msdn.microsoft.com/en-us/library/ms151198.aspx
I need to create a trigger on one server to fire when a certain table is changed, after which I have to do some calculation with the data so I can import (it's no just copying) it into another table on a different server.
Also I only want to import the new data that hasn't been imported through a earlier trigger.
How would I go about this?
Create Linked Server to your target server, then use MERGE statement to perform action depending on existence of record in destination table.
I would refrain from creating triggers referring remote servers though, it might have performance and reliability implications. Consider using Service Broker if you want to achieve small latency and still make the update reliable.
You can create a linked server between two SQL Servers to send data from one to the other.
To create a linked server you need to use the system stored procedure sp_addlinkedserver, you can also do it through SQL Server Management Studio I believe.
Here is an example you can try:
EXECUTE sp_addlinkedserver #server=N'serverip/hostname', #provider=N'SQLNCLI'
You can view if your linked server has been created by querying sys.servers
You can query the linked server database with the following syntax:
SELECT x
FROM [linkedservername].[database].[schema].[table]
More information: http://msdn.microsoft.com/en-us/library/ff772782.aspx
For the trigger updating only data which hasn't been handled before. There are many ways you can do this. If your source table has an 'update date' type column, you can do it based on that. Alternatively, if your table has an identity column and you want to copy data incrementally you can store in a table the 'last id' which is copied over each time, then on the next run of the trigger you can tell it to start from that id+1 that way rows are only transferred once.
I have a form with data. Any changes or insertion , those data should be updated in tow different tables like name, salary in one table and address, mail id in another table.
Like the example above i have several columns in both tables.
Now i want to audit the table. So i think i have to create a view for the two tables and set up a trigger for the view. Is it correct?.
And also i need to know only the affected columns. How to get the only affected columns?
Please suggest me a solution.
Thanks!!
There are lots of ways to let the system handle all that grunt work for you - depending on the SQL Server version you're using:
How to: Use SQL Server Change Tracking (as of SQL Server 2008)
Introduction to SQL Server change tracking
Understanding SQL Server Audit (as of SQL Server 2008 R2)
Articles for SQL Server Auditing (various versions)
If you really must handle all the work yourself, you need to get familiarized with triggers - read up on them in Data Points: Exploring SQL Server Triggers.
Inside your trigger code, you have two "pseudo-tables":
Inserted is the table holding the values being inserted (in an INSERT trigger) or the new values (in an UPDATE trigger)
Deleted is the table holding the values being deleted (in a DELETE trigger) or the old values (in an UPDATE trigger)
With those two pseudo-tables, you can get access to all data you might need.
Is there a way to replicate a sql server database but not push out deletes to the subscribers?
You don't mention which version of SQL Server you're running, but Andy Warren wrote an article on configuring INSERT, UPDATE, and DELETE behaviour in SQL Server 2005. You can configure this through the GUI, using his instructions:
http://www.sqlservercentral.com/articles/Replication/3202/
It's tempting to 'intervene' in a normal replication and 'disarm' the subscriber's side delete stored procedures, but this leaves no option to recover from replication failure. If the replication tries to recover, a reinitialize may be needed and this will drop any 'stale' data that the replication agent considers deleted.
An alternative is to use a normal replication, and use a script that generates insert and update triggers on all tables in the subscriber database, that insert/update that data into yet a third database. This way the third DB will collect all the data that ever existed, the second DB can re-initialize it's subscription if it needs to (when you do, just remember that bulk inserts don't call the insert trigger and check for new data and add it to the third DB), and the first DB doesn't have to perform the extra work that the triggers are.
Do this....Drop the article. Create a new storedprocedure in the corresponding database that mimicks the system store procedure (sp_del...) and contains the same parameter but does nothing. Add the article again...and set the delete store procedure under the article's properties to the new delete stored procedure that you created....
Or you can select Do not replicate Delete Statements....I think that works but i haven't tried it.