I've been trying, googling and hitting my head against the wall but can't figure our what the problem is or how to solve it.
I have and SQL 2005 Standard server acting as a publisher. I need to do transactional replication to an SQL 2008 R2 Web server on another location.
I've set up the publication, and enabled FTP access to get the snapshot.
On the 2005 server when I launch replication monitor it keeps saying Uninitialized Subscription.
If I test this with a different subscriber that is running SQL 2008 Enterprise, it works fine.
Could it be because of the version? Could it be the SQL 2008 R2 Web can't work as a subscriber with SQL 2005?
Thanks,
Federico
Mixed versions are supported, but:
Distributor version must always be equal or newer than Publisher
Subscribers for transactional replication can be within 2 versions newer/older of Publisher
Subscribers for merge replication must be equal or older than Publisher
You need to troubleshoot to verify initial setup. I would suggest you to setup Replication using GUI
http://www.sql-server-performance.com/2010/transactional-replication-2008-r2/ (Should be similar in SQL 2005) as well
To do a clean installation please drop existing setup (Publisher, Subscriber, Distribution DBs)
How to cleanup Replication Bits - http://blogs.msdn.com/b/repltalk/archive/2010/11/17/how-to-cleanup-replication-bits.aspx
The comment listed below is from our SQL PFE. I am still trying to get some documentation.
"Publisher version must be equal to or greater than the Subscriber version."
Related
During our development cycle we create migration-scripts that will be executed on multiple Microsoft SQL Server instances (on different servers).
Since these servers are being maintained by multiple third parties, we can't guarantee that all of them are using the latest Microsoft SQL Server version. For example, some of them are still stuck on 2008 R2.
Unfortunatly, this means that our SQL scripts must at least be compatible with 2008 R2 (and higher).
We would like to add an extra step to our build process (currently driven by MSbuild), which should check if all scripts are compatible with all versions of SQL Server that we should support (2008 R2 and higher). Both in terms of their syntax, but also in terms of built in functions (as an example, the CONCAT-function was only added in 2012).
However, we want to avoid having to install each supported SQL Server version and instead use only SQL Server 2017.
Note:
I've had a look at compatibility modes in SQL Server, but when I set the compatibility level to 100, I seem to still be able to use SQL Server 2012 features like the CONCAT-function. Which doesn't surprise me, as I expect this to be intended for backward compatibility, rather than blocking features.
These similar questions didn't really help either: Using SQL Server Express 2008 with SQL Server 2005 database -how to check for compatibility, How to check sql script compatibility agains SQL 2008
Are there any other options?
I want to setup mirroring between 2 copies of SQL server. The primary box is SQL server enterprise edition.
Can I mirror it to a SQL server standard edition? The purpose is to save a metric ton of money.
From Books Online:
The two partners, that is the principal server and mirror server, must be running the same edition of SQL Server. The witness, if any, can run on any edition of SQL Server that supports database mirroring.
That being said, it is possible to set it up as long as you use TSQL commands and not the GUI. I would never recommend it, but it is possible, as long as you guarantee you're not using any Enterprise features. More warnings HERE and HERE.
Last edit - apparently this has been completely blocked in SQL 2012. Looks like you're out of luck.
I have a main SQL Server, running SQLServer 2000, with two (in theory) subscribing servers, each running SQL Server 2005.
One of these is subscribing fine, but the other always seems to fail subscribing, both when attempting to set up the subscription from the publisher (SQL2000) to the subscriber(SQL2005), and when trying to set it up from the subscriber to the publisher, both via Server Management Studio 2008 and via SQL Enterprise Manager
In both cases, the publication is created on the publisher, but a corresponding subscription is not created on the subscriber.
I then get an error message saying "The process could not connect to Subscriber [ServerName]", and no more sign of activity. There's no problem with logins, permissions, etc. The password for sa is the same on both machines, and is different on the 2005 machine that works.
Is this a problem anyone else has encountered?
EDIT: I've now tried adding both a dbSubscriber and a dbPublisher access account on each server so that they're not logging into each other using "sa", but it doesn't seem to have made any difference.
EDIT2: Adding a push subscription does not create a Local Subscription on the subscribing server. Is this normal, or is this the point at which everything is falling to pieces?
Thanks for posting an update, always good to know how things turned out.
There are "complications" and intracacies involved when creating SQL Server Replication topologies incorporating different versions of SQL Server, as it sounds like you are discovering.
Keep in mind that Replication functionality is limited to that of the oldest version of SQL Server in your topology:
Using Multiple Versions of SQL Server in a Replication Topology
We don't really understand what was going wrong, but we think that the 2005 server was unable to accept the 2000 server as a Push Publisher.
We created four different Pull subscriptions on the 2005 server and the first three failed, while the fourth magically worked.
We are accepting this as a blessing from the God of Computers and will not question His benevolence.
My company is planning to migrate it's intranet/internet based ERP to the latest form of MS SQL Database available.
Presently we are using SQL Server 2000 Professional.
And we are planning to shift to SQL Server 2008 Web edition.
Please tell me whether this is the right step and whether it is feasible or not.
Thank you in advance.
"Please tell me whether this is the right step " - that's something you and your company need to decide.
It is feasible, and in the majority of cases straight forward.
Your first step should be to run the Microsoft SQL Server 2008 Upgrade Advisor
Microsoft SQL Server 2008 R2 Feature Pack contains the Microsoft SQL Server 2008 R2 Upgrade Advisor
Formulate and test a rollback plan
Determine your upgrade window and acceptable downtime.
Ensure database consistency: Run DBCC CHECKDB on databases to be upgraded to ensure that they are in a consistent state before performing the upgrade.
Back up all important files: Back up all SQL Server databases from the instance to be upgraded (including master, model and msdb), data and transaction log files, as well as any application files, script files, extract files, etc. so that you can completely restore them in the event of a failure.
It's both feasible and easy. The path from one version of SQL Server to another is usually pretty simple. Do you have any special stored procedures or reports generated in SQL Server that need to be rewritten/re-imported?
As far as right step - the question is, Why? If it's working, do you really need to mess with it?
If it's for intranet (some app for your internal usage) then consider using SQL 2008 Express edition. It's free and you can use it as an instance running along the full 2000 version. That way you will have some extra features from the full version.
But you have to know that applications running on SQL 2000 may not work on 2008 and they are even more probable not to work on 2008 R2.
We have a Sql Server 2005 Standard Edition running on a Production website. We'd like to move to a cloud hosting but they only offer Sql Server Express Edition on there.
My question is, will there be any problems in moving over? We only use tables, views, stored procedures and a few user defined functions. And we also have a Backup Maintenance Plan in place. Will any if this change?
WHat other limitations/problems (if any) can we expect to have? And is it a good idea to run on Express in Production?
And I would like to add, will it be OK if we moved from SQL server 2005 Standard to Sql Server 2008 Express - what possible problems there could be with this move?
There are limitations for SQL Server 2005 Express as listed here
These include:
- max 1GB RAM only
- max DB size of 4GB
- 1 CPU
Theses restrictions may cause you a problem. See the full list in the link.
With regrd to moving from 2005 Standard, to 2008 Express, then I expect the limitations of Express Edition may be the main factor when you consider if it really is an option. The limitations for 2008 Express are similar, see here.
Hope this helps
The migration im unsure.
Express does not support triggers (fully), nor SQL scheudling.
Its size is limited to 4GB.
You can only ever have one instance with express.
It does however support Full Text and Reporting Services (in the express advanced edition)
We have plenty of clients running SQL Express due to cost. Only small pain has been the need to write a windows service for a job that could be easily run in proper SQL scheduling in the paid for the version.
Im sure there are many more differences but these are the ones im aware of, hope this helps.
I've used SQL Server Express for simple data persistence in production with no issues.
From the looks of your situation the only feature that will not be supported is backup maintenance. However, if you're hosted on a cloud, your ISP should take care of backup for you.