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.
Related
I have successfully configured merge replication on my local SQL server by creating two instances making one as Publisher and other as distributor.
Now to show demo to my client i need it to configure live by making my local system as Subscriber and any live sql server as publisher, can any one guide me that where should i configure live server ? As if i go to any paid SQL Standard edition it will cost me more than my salary , i just need to show demo to client. Can i install SQL Developer on any windows hosting? or there isn't any other option than buying server
If you want to Setup Merge Replication Demo on your local, then install 2 SQL Server instance or you can perform on same server as well. But for the better understanding you can consider one instance as a publisher and second as a subscriber.
Now, configure replication with Publisher and Distributor on Server-1 and subscriber on Server-2.
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'.
I searched everywhere but couldn't find an answer. I know LocalDB cannot be a subscriber to merge replication. But what about transactional replication?
I've tried both the SQL Server Management Studio and RMO programming to create a pull subscription to a publication with type of transactional replication, but it keeps telling me "replication is not installed on this instance of SQL server". There is no option for me or the user to select replication feature during the install. And re-installing LocalDB won't do any help.
I know it is possible to use sync framework to do the job but it is something new to me and I've already deployed LocalDB to the clients computer in my previous software release, so I prefer to stick around with the replication method before I know for sure that LocalDB doesn't support any form of replication.
To summarize my question: How do I create a pull subscription on a LocalDB instance to subscribe to a transactional replication?
BTW, the LocalDB is deployed to the clients computers using the bootstrapper came with Windows 8 SDK, which can be found in this directory if you have one installed: {C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\Bootstrapper\Packages\SqlLocalDB2012}
I would be happy to provide more information if I didn't make it clear. Thanks in advance!
Based on your question: "How do I create a pull subscription on a LocalDB instance to subscribe to a transactional replication?", the answer is simple. You can't.
Setting up a pull subscription requires replication components to be installed (they're not), and requires Agent to be installed (it's not).
I think you have a reasonable chance of getting a push subscription set up, as all the serious code happens on the distributor.
The problem, I find in your question is that you were not able to setup transactional replication in a Local DB instance.
I want to add my work on Transactional Replication.
Recently, I created Two Local SQL Server instances. I setup Transactional replication among these two SQL Server instances without any problem. I hope this helps. Please comment if there is any question on this.
I have to setup a database for reporting, and I chose transactional replication for that because it seems the easiest way (setup has to be easy, i will have to explain to customers how to do that). Now for that i do need a distributor database, and i found information that it should not be on the publisher. As there will only be one subscriber, and the performance of the publisher matters alot and the performance of the subscriber does not, I was thinking of setting up the distributor on the subscriber. Does that make sense and is that even possible?
Flo,
Yes, this is a popular configuration. You'll want to configure distribution on the Subscriber and have it act as a remote Distributor for the Publisher. After configuring distribution on the Subscriber and creating the publication on the Publisher, you can then create the subscription on the Subscriber.
Remote Distributors are covered in Configuring Distribution and in How to: Configure Publishing and Distribution (SQL Server Management Studio).
Hope this helps.
We have Merge (Push) replication set up between the databases in our different offices. Each database carries the complete set of data, so that the users in each office only need to connect to the database server in their office. When users want to go off-site they need to pull a subset of data to a local (on user's laptop) SQL Express database. Is it possible to use SQL Server 2005 replication to pull this subset from one of the Subscriber databases and then later replicate their local changes back?
Edit: We do not want the users in regional offices to replicate against our main publisher database, but against the Subscriber databases. Each Subscriber must therefore act as a Publisher for the users in that office (maybe even using transactional replication in stead of merge replication)
Yes, but make the offsite users' SQL Server 2005 Express Edition a merge replication subscriber (i.e. pointing at your Distributor).
Ref.