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.
Related
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.
I use TOS to transfer a SQL Server table to another SQL Server. That works more or less. But I have one issue with truncating the table. In the properties for the output table I define "Truncate Table" for the table action and "Insert" for the data action. At the second run I get a lot of duplicate key errors. If I run the "TRUNCATE TABLE" manually in the SQL Server Management Studio, the job works fine.
Are there any known issues with truncate table? Talens Version is 5.3.2
Thanks in advance
I mimicked the scenario and it works fine in Talend Platform for data Management version 5.6.1. I cannot test it on the TOS, but perhaps you can upgrade to the newest TOS version and try again. To be thorough I tried it using separate connection components and built-in connections. The only difference is that using separate connection object requires a commit object.
The workaround I recommend is this:
create a proc to truncate your table and call it from a tMSSqlSP component
connect this to your original subjob which transfers the data between the two tables using an OnSubJobOK flow.
In your tMSSqlOutput component (which performs the truncate/insert) in for Action on Table use Default (so it will not truncate the table)
for Action on data use Insert
I tried this method and it works. This workaround will save you the time and frustration of dealing with the TOS issue.
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.
When the table's rows are changed, these changed rows are written to XML, and let me know that the table has been changed.
How can I do this?
If you're looking for a strict TSQL or SQL Server solution:
write a stored procedure to handle UPDATE, DELETE and INSERT functionality.
deny UPDATE, DELETE and INSERT to users
allow EXEC to users on this new stored proc
on each call to the stored proc, make an entry into another table, specifically built for auditing.
write a SQL Job to poll this audit table for new records. Use SQL Mail to send email. You weren't clear about what kind of notification you wanted, but I assumed email.
2nd less attractive solution: You could also use triggers on the table to capture the UPDATE, DELETE and INSERT activity. Strongly consider the stored proc solution over triggers.
If you can't alter how data is being changed in your table, the best solution would be to setup a trigger to capture changes in a separate table, and then write some code to periodically poll this table, and build your xml file.
Its worth noting that this will potentially slow down your db performance when editing data in this table (good for audit when users are making changes, bad for programatically changed data), and any errors coming from the trigger lead to quite misleading messages thrown back out of sql server.
See this question for some pointers on setting up the trigger.