I have one SQL Server Express instance with a pretty normal well formed database. I need to have the data continuously replicated to a SQL Server Express instance on another server.
Now, I know that SQL Server Express does not include the Publisher part of built-in replication, so I'm looking for alternative solutions. I do not want to upgrade any of the databases.
Naturally, I could make my own replication with guids, timestamps etc. and transfer the data using my own coding(as suggested in SQL Server Express database replication/synchronization), but I would want to avoid all that work, especially seeing that the replication is really very basic.
Perhaps a generic trigger added to each table?
Perhaps some kind of database job?
Any suggestions?
You wouldn't be able to utilize any built-in job scheduling, because Express does not ship with SQL Server Agent.
Here's your options as far as I see it:
Write an application that transfers "articles" from your "publisher" db to your "subscriber" db(s)
Create a set of views to have a summation of data that you want to be published. Then create INSTEAD OF triggers on these views (you can't create an AFTER/FOR trigger on a view) to process that data and transfer it to your "subscriber"(s).
Those are both not very intensive tasks. In my opinion, just to have it centralized I would go the first route. That way all of the logic is contained within the application, and your "publisher" database is ignorant to the replication. Not to mention your application could handle an unavailable subscriber pretty easy.
Related
I recently moved a SQL Server 2012 database from an old web server to Azure SQL. I also keep a copy of the database on my personal machine which is now running SQL Server 2019. During development, I frequently make changes to tables on my local machine and then need to transfer those tables to the server. I used to do this using a Visual Studio SSIS package. It was very easy. I used the "Transfer SQL Server Objects" task to select one or more tables, specify whether the existing tables should be dropped first, and replaced the tables on the server. The "Transfer SQL Server Objects" task does not work when trying to transfer objects to Azure SQL because it uses the "USE" statement. There must be an easy way to transfer tables to an Azure SQL database. I've used the "Microsoft Data Migration Assistant" and it works great for the initial migration, but does not allow you to replace tables. I feel like I am missing something very obvious because transferring tables is a routine task and there must be an easy way to do this with Azure SQL.
Manually managing and synchronizing different database versions can be time-consuming. The Schema Compare addon facilitates database comparison and provides you complete control when syncing them — you may filter particular differences and categories of differences before making modifications. The Schema Compare addon is a trustworthy tool that will save you time and code.
Hence, the Schema Compare extension provides an easy-to-use experience
to compare two database definitions and apply the differences from the
source to the target. MSFT Ddocument which could be usefull : Schema
Compare extension- here and How to: Use Schema Compare to Compare
Different Database Definitions - Here.
I have a transactional database (SQL Server 2014) with around 60 tables, and there is a requirement to create a separate reporting database for reporting purposes.
This will only need to run every 24 hours - however I will be needing to move the data into a different, more query-friendly schema!
Because of this I would hope I could just create some Views on the Transactional Db and then create a table based on that view in the Reporting db and copy across the data.
I originally thought of writing a scheduled Windows Service that somehow extracts data from the tables and inserts into the new one, but then thought if the schema changes it has to update in two places, and also thought surely an enterprise SQL Server license must have some tricks.
I then looked into 'database mirroring' on specific tables but this looks to soon be deprecated.
'Log shipping' looks like more of a disaster recovery solution!
Is there an industry 'best' approach to this problem?
You will need to devise an ETL process to extract data from your source database, transform it and load it into your reporting database. There are many tools available to you to make this easier. You can use SSIS, Azure Data Factory for Azure SQL, and there are many other options. You can use the SQL Agent to schedule stored procedures to run your ETL process.
Your target database will look much different than your source database. There is really no quick way (quick as in scheduling a backup) to accomplish this. There is a lot of information on data warehouse and ETL design available to you to assist you in deciding how to proceed.
We have an firebird database connected to our access control system and then a separate web app that I developed for our time and attendance using sql server 2005 as the data source.
I wanted to use entity framework to connect to the firebird database to access data like users, transactions, sites, etc. As this method is very complicated getting the connection using firebird .NET provider the other option I have is creating a sort of replication (Mirror) from the firebird database to sql server.
I have done this with a DTS previously (Selecting the data and then inserting it) and it worked fine but had many manual processes involved in getting the data and updates made it difficult.
Is there a simpler way to do this or any suggestions would be appreciated.
Unfortunately you need to track what to replicate at the data level. If you are only pushing it to the MS SQL database you could use a modified timestamp, or a record version field (create a generator, set a trigger to update the version field upon update) to reduce what you select. Another popular option is to update a field to current_transaction, but if you do a restore you will start counting from 0.
If you are sending data both ways it gets more complicated -- you need to have conflict resolution. You could look at something like the Microsoft Sync Framework which can use the methods above.
I have a vb.net project that uses a SQLite database. I do this by using dataset/table adapters. The client is happy and all works well. However I have just heard that they plan on providing this product to another customer that wishes to use their SQL Server database. So I am writing this post so I can mentally prepare for this before I begin. I am not a database pro and have really enjoyed the simplicity of setting up and managing an SQLite database.
So any ideas on the easiest way to support SQL Server as well? I am happy to run them parallel to each other. Can I just make a separate service / middleware that syncs the SQLite database to the SQL Server on a timer and does not care about what the main app is up to?
Any pointers are appreciated.
Synchronizing two databases is possible, if rather complex. You need some mechanism to find out which records have changed, and if it is possible to have new changes in both databases, you also have to resolve conflicts.
A timer-based approach doesn't sound efficient: in most cases, the timer doesn't have anything to do; and after some data change, there is some amount time where the databases are not synchronized.
Can't you just replace SQLite with MS SQL Server?
I.e., have some configuration settings that determines whether your program's data lies in SQLite or on a server?
Assuming that an SQL Server database with the required structure already exist, this would, in theory, need nothing more than a changed connection string, and supplying some user name/password (if the server isn't configured to automatically use Windows logins).
There shouldn't be any big differences in the SQL dialects used. You have, of course, to test all your queries.
I'm using two SQL Server, one is SQL Server 2000 and the other one is SQL Server 2005.
When the table1 in SQL Server 2000 gets updated/inserted/deleted, I have to update another table in SQL Server 2005. Is it possible to achieve that in a trigger? If not, what would be the possible options?
Thank you, have a nice day!
If you're wanting to replicate the data, not just set something differently, you should look at SQL Replication as it'll manage things a lot better. eg it will do the updates asynchronously.
If you have to do them synchronously, or you just decide it's simpler or you need the whole operation wrapped as a single transaction, I'd put the logic in a procedure for cleanliness. You can create a linked server from 2000 to 2005 and refer to the table from there as SERVER.DATABASE.SCHEMA.TABLE. Alternatively you could execute a stored procedure on the remote server to do the insert/update/delete.
If you don't want SQL replication you might instead consider writing the insert/update/deletes from 2000 into a separate table within the same database, via the trigger. Then have a separate job that writes these changes to 2005 then removes them from the table. This would mean you could batch up the changes, mean updates to the original table would be done quicker, would deal better with lost connectivity between the two servers. However, you have less guarantee that the updates would actually be applied to the 2005 server, and you have the added complexity of a sql job that must be run. So it's a tradeoff. And once you start writing and maintaining this sort of logic you realise that's why MS wrote replication stuff, so you don't have to.
It is possible to use linked server and a trigger but I have only bad experiences from this.
Why not use triggers?
Two-way sync with triggers is tricky, because the triggers will fire each other. You will have to control this somehow, for example with special values.
Otherwise, you will get strange locking errors.
You will need to set up MSDTC (Distributed Transaction Coordinator) between linked servers
DBMS can't help you very much with linked servers. it is much harder to debug SQL. Bad queries usually just hang and timeout when there is type mismatch etc.
Transactions with multiple writes in the trigger OR in the query launching the trigger cause deadlocks easily. I would use triggers only to very simple updates (one INSERT/UPDATE/DELETE statement) and even then make sure that deadlocks cannot occur. I remember one integration that I had to rewrite completely when a legacy app caused deadlocks with a trigger.
Alternatives
There are at least two questions to answer:
Is the synch one-way or two-way between tables?
Do the schemas of the two tables match?
If the schemas match, replication should be ideal for both one-way and two-way synch.
If the schemas are different, like usually is the case with application integration (EAI), you might consider:
Integration Services (SSIS) or even Import/Export tool -generated dtsx package
Some other EAI tool, if available (like BizTalk)
programming a custom integration tool
I don't have much experience with EAI tools but comparing SSIS to custom .NET solutions I can only say that you will save a lot of time if you can get the job done with SSIS.
Only if SSIS does not work or is not available (SQL Express) I would try programming a Windows service, WCF service etc.
Yes, you can do this using a linked server and an trigger on the database that is being updated.
SO inside your trigger you would do something like this.
UPDATE linkedserver.Database1.dbo.myTable
SET ...
WHERE ---
with your values for the set and WHERE.
Now, th eonly thing would be how the linked server is setup between 2000 and 2005, you would have to try that out first.