I’m always very leery about changing, and mixing, SQL Server versions! Maybe not as much as changing/mixing OS, but I have hit the odd nasty problem by assuming that SQL vX will be near enough the same as SQL vX.1. They are different products that require a planned upgrade, even if that plan is short.

I’ve certainly been burned before with databases that stopped working from 2005 to 2008, compatibility setting or no, because the optimizer changed and queries that used to run fast suddenly took minutes to run.

Are you able to take a SQL 2008 database set to 80 compatibility level and restore it on a SQL 2000 box? I have no idea, but I’d assume not. From memory, even 2008SP1 databases wouldn’t back-restore to 2008.

Hmm, a backport via scripting shouldn’t be unreasonable even for large databases (though agreed, 200GB would be pushing it a lot!) – or backport the schema and use SSIS or linked server queries to bring the data across. Slow but you’ll get there in the end.

Guess the main thing though – start by assuming that the upgrade will fail and that downgrades via backup/restore will NOT work, and then TEST before doing anything irrevocable. Also assume that if your dev environment is 2008R2 and prod is 2008, then even if migration works fine, you’ll end up with nasty, subtle incompatibilities that don’t show up til the demo for the CEO…

It’s not like it’s even hard to just script out the schema and data to downgrade. But I really don’t have much sympathy here, if you put the latest toys on your dev box, don’t expect anything to work when you try to move your stuff across to the older stuff that’s running elsewhere.

Frankly I’m astonished why anyone would expect to be able to go from a later to an earlier version of SQL via backup/restore. Is it the naming that is confusing you, maybe? SQL SERVER 2008 R2 IS A NEW VERSION, not a service pack! In other news, no you can’t go from 2008 R2 to SQL Server 6.5 either…

I can confirm the same problem still exists in SQL Server 2008 SP1 and I have found NO other documentation regarding this issue.

IMHO it is a bug not a limitation. If periods are not allowed then validate the name of the publication before allowing it to be saved! It won’t allow merge publications if there is anything (ANYTHING) else wrong with your database but will allow the publication name to be saved to prevent resolving conflicts. Just ridiculous and has caused many hours of frustration!

I had exactly the same error and caused by that blasted dot. In my case I found out about it at the end of a republisher pushing out filtered subscriptions and had to roll all the way back to the central publisher and start all over again, again…

Another “dot-related” issue to be aware of for merge replication…
For example, I have schema [A] and schema [B] both have tables called [Info].
I have filtered replication going on A.Info and wanted to use joins to enforce integrity on other filtered articles.

So the example WHERE clause would be “WHERE A.Info.ID = B.Info.ID”

Joins in filtered replications ONLY support 2 part naming conventions!
This means the valid caluse has to be “WHERE Info.ID = Info.ID”
The builder is automated so you can’t alias anything and are stuck with it.
My work around was to create a seperate filter for each table rather than using the Joins.

Despite the setup issues with merge replication, once it is up and running it is great stuff.
I still recommend creating back up jobs on all subscribers (ours are SQL Express 2008) and purchasing RedGate’s SQL Toolbelt so data compares can be done in the case of failures or data loss.