Comments
1 comment
-
The problem isn't that the database is on a remote server, but that the new target server is a 2005 server. Whilst we can get around the encryption on 2000 servers and retrieve details about the objects, we can't do that on 2005 servers (because they improved the encryption). As we can't see the details of the objects on the 2005 server, we have to assume that any incoming object might be different to that object, which is why the migration script wants to migrate everything.
You might be able to work around this by finding out which objects you've changed (by seeing which ones are synchronized to your 2000 clone database) and only selecting those objects for synchronization. Other than that, I don't think there's a way to do what you want (because we just can't see what the state of the encrypted objects on the 2005 server is).
Add comment
Please sign in to leave a comment.
I've got a development database and a clone of the development database that I was testing the add 'WITH ENCRYPTION' option on. It's a SQL 2000 SP4 server and I found the option works fine, I ran the encryption the first time and it worked fine. I made a change in the development and synchronised that object to the clone database and it worked fine, it only synchronised the change.
However, I went to apply this onsite at a clients end (VIA a VPN and to a SQL 2005 Server) and had an issue where, once the objects were encrypted, it worked, once I wanted to re-sync a change or two from the development database it wanted to re-create every object. (I think this has to do with every server having its own encryption setting, but not certain)
Is there a way that we could save a setting or remote key that would allow us to only sync the changes across 2 different servers? Or does this have to be done with a copy of the development database on the client's server?,