I have a device that continuously collects data and stores it on a local database. I would like to also replicate that data to a second computer over the network every 10 seconds to ensure data reliability. Should I use transaction replication to achieve this? What if the network connection is temporarily unavailable, will the replication service automatically transmit all the backlogged data once the connection is restored? Can the computer that collects the data be SQL Server Compact or does it have to be at least Workgroup edition to be a Publisher. The second PC will run SQL Server Express and would be a subscriber. Thanks.
I'd prefer to use mirroring or log shipping for something like this, but those options are off the table if your second PC is running Express.
The distribution agent will retry, however if the disconnect continues for an extended amount of time, your subscription may be deactivated or expired/dropped.
Your publisher must be at least Workgroup edition (which limits the number of subscribers).
See these links for the specifics on which editions support which features.
SQL 2008 Editions/Features
SQL 2005 Editions/Features
I think you will need at least work group edition to be your publisher. Other than that yes transaction replication should do the trick. It can run continuously and the "backlogged" data will be replicated once connectivity is restored.
Related
I have two sql servers
Windows Server 2008R2 SQL Server 2012
Windows Server 2012R2 SQL Server 2016
I want to mirror one of the databases to the other.
Will it work on different sql versions or cause problems?
The summary is-
The principal and mirror server instances must be running on the same version of SQL Server. While it is possible for the mirror server to have a higher version of SQL Server, this configuration is only recommended during a carefully planned upgrade process. In such a configuration, you run the risk of an automatic failover, in which data movement is automatically suspended because data cannot move to a lower version of SQL Server.
For more details, please visit Here
Will it work on different SQL Versions or cause problems?
Yes, but it will work only when Primary is Lower and Secondary is Higher version, as it already confirmed by MkRabbani, you need to plan it accordingly.
Consider, by any chance if fail-over happened the database cannot be reverted back (by fail-over again). So, it's possible but depends on your scenario how do you want use Mirroring, Log Shipping etc.. as all work in same manner (always lower to higher version possible, but not higher to lower).
I'm currently working on a project proposal which would require moving multiple Access databases into a new MS SQL Server database. The idea is to keep the front end program as MS Access so that the users are familiar with the process of inputting data and creating reports.
However, things get complicated in that the internet in the areas where the survey will be collected has poor connectivity and will be out from time to time. I had thought of a few ways of solving this issue but all of them are cumbersome:
1) Having a PC with a router that stores the SQL Server database in offline mode and the data entry PCs connect to the PC with the offline database through the router. The PC with the SQL Server database can then backup the db on the server when it has an internet connection.
2) Adding the data to MS Access databases that can then be merged with the SQL Server at specified increments (this would probably cause some issues).
We've done option 1 before for similar projects but never for connecting to an SQL Server database in offline mode. However, it seems feasible.
My question is: Does anyone know of a way of using Access as a front end application for SQL Server and being able to update data during times without internet connectivity? The SQL Server database would automatically assign primary keys, so, duplicate unique values shouldn't be an issue while syncing the data.
Thanks for your help. I've been having a hard time finding an answer on Google and syncing to databases is complicated at the best of times. I'm really just looking for a starting point to see if there are easier ways of accomplishing this.
I would run a the free editon of SQL express on all laptops. So the Access database would be the front end to the local edition of SQL express. SQL express can be a subscriber to the "main" sql database. You thus use SQL replication to sync those local editions of SQL server to the master server. Of course the main SQL server can't be the free edition of SQL server. So to publish the database for replication, you can't use the free edition, but those free editions can certainly be used as subscribers.
This approach would eliminate the need to build or write special software for the Access application. You thus do a traditional migration of the access back end (data tables) to sql server, and then simply run the Access application local with sql express installed on each laptop. You then fire off a sync to the main edition of sql server when such laptops are back at the office.
The other possible would be to adopt and use the net sync framework. This would also allow sync, and would eliminate the need to run sql expess on each machine. I think the least amount of effort is to sync the local editions of sql express with the main editon of SQL server running at the office (but that office edition of SQL server can't be a free edition).
Summary: Is there anything new in SQL Server 2014 (versus 2008 R2) that does not allow the following scenario? Can the same approach be transfered to the new server?
The application uses SQL Service Broker to collect data from satellite SQL Express machines (technology computers, now two, soon 4, and possibly more) to the central SQL Server with SQL Server Standard edition.
It is based on simplified security settings without the need to exchange certificates. I was asked to migrate the solution from SQL Server 2008 R2 to SQL Server 2014.
The situation was described in details at SQL Service Broker -- one central SQL and more satelite SQL... beginner wants to understand details and the solution was based on the Remus Rusanu's answer.
Yes. All SQL Server releases, from 2005 to 2014 inclusive, are compatible with each other at the Service Broker layer. In fact the 2008 instances are not even going to be able to figure out they are talking to 2014.
You should be able to migrate one machine at a time, w/o taking down everything. If the upgrades are don in-place (keeping the machine name the same and preserving the SSB endpoint settings) then you won't have to change anything after the upgrade, it should just keep working.
If you do side-by-side upgrade then you will have to port the SSB endpoint settings and certificates used from one instance to the other, along with moving the database.
Keep in mind that if you have a problem and you are forced to rollback to a backup then your entire, distributed, system state will not be consistent (basically conversations will no longer match the send sequence number and receive sequence numbers) and you may have to force some close conversations (manual END ... WITH CLEANUP on a case by case) or nuke the entire broker in the DB (ALTER DATABASE ... SET NEW_BROKER). Lets hope you won't have to do this. If is feasible then you could simply stop the entire system (eg. run ALTER ENDPOINT ... STATE = STOPPED on all 3 nodes to stop all SSB communication) and then do a backup and then do the upgrade, now being safe to rollback the upgrade and restore since everythign is 'frozen'.
Recently we installed a new Sql Server 2008 server for a client and we had to move all the databases for them. Apparently they forgot about one application that uses replication with local Sql 2000 Desktop Edition instances. Now we're trying to get the replication running again.
Currently we get the error: The server '...' is not configured as distributor.
2 questions about that:
Is there a way to detect the type of replication used by just looking at the DB schema?
I'm guessing we don't need to run the replication wizard again since that changes the database schema which should be already ok. What do we need to do to manually hook up everything?
Apparently you made a fresh SQL Server installation, and not an upgrade, which would have been the recommended approach.
It seems that you can use both main types of replication now: merge replication and transactional replication (see this article)
Since you have a fresh installation, creating the publication from scratch is a must.
I recommend following the usual steps when setting up replication:
If at your subscriber you also need to make schema or data modifications then choose merge replication. If your subscribers are read-only or you don't need schema/data altered there, choose transactional replication.
Create your publication in SQL Server 2008. The distributor should also be this instance (because of replication rules between different versions of SQL Server - the distributor has to be the no earlier than the publisher). Choose your articles, snapshot agent schedule, security settings.
Initialize snapshot.
Re-create your MSDE 2000 subscription. Note that all agents should run at the Distributor.
You have to figure out your security settings. Especially how your subscribers connect to the publisher (SQL credentials or integrated security if in a domain).
So, recreating your publication shouldn't be very hard.
If you previously had merge replication setup then a real problem could be data at the subscribers that hasn't been uploaded to then publisher yet. So you have a bunch of subscribers all with their own modifications. In this situation you either discard the data or manually backup each subscriber and synchronize it after subscription initialization.
What ports or modes of communication do you need to open up for SQL Server 2005 Transactional Replication? Main and slave are geographically separated.
Make sure you enable encryption, otherwise your replicated data could be sniffed by any one in between. The better solution would be to set up a VPN between your two locations to off load the encryption from SQL Server and also provide better security.
I believe TCP Port 1433 is typical although it can be defined by the publisher
Here is a decent article on this.
(Not an Answer)
I regretted using SQL Replication back during the SQL Server 7 days. From what I've seen of SQL Server 2005, The tools have become more unusable.
If I were in your position, I would look at some form of Transaction server that supports replication and set it up as a middle tier between your application and your database(s).