Comments
3 comments
-
Ken,
Did you have the SQL Compare add WITH ENCRYPTION option enabled? You can find it in the Project Configuation Dialog > Options Tab > More Options > Behavior section.
Having said that the default you have pasted in should not be encryptable so that is very very strange. Can you post what you were changing the default too? As this might be SQL Compare saying that it cannot read the default, though I have not seen this before.
If you have the two test case database that exhibits this behaviour can you forward me on the schema if you are able to?
Regards,
Jonathan -
Hi Jonathan.
I checked out the options and they appear default - ie encryption is not enabled.
Having checked out the destination table manually it appears ok also. Cant see anything that says its encrypted.
Seems SC just isnt reading the destination schema right?
I can send you the schema confidentially if you wish?
Regards.
ken. -
I have PMed you about this.
Regards,
Jonathan
Add comment
Please sign in to leave a comment.
Run a compare on 2 sql2005 database in order to synch them up.
Then ran the short script to synch them, then ran a compare again.
The second database now seems to be massively different from the first. Simple text in stored procedures claims to be encypted in the altered database according to SQL Compare. and when I try to re-synch it claims the procedures cannot be decrypted and thefore impossible to compare.
Nothing in the database should be encrypted - certainly each database was NOT encrypted before the compare job. Any ideas?
An example:
database 1: [invoice_text] [nvarchar] (255) COLLATE Latin1_General_CI_AS NULL CONSTRAINT [DF_tbl_billing_codes_invoice_text] DEFAULT (''),
database 2 after synch: [invoice_text] [nvarchar] (255) COLLATE Latin1_General_CI_AS NULL CONSTRAINT [DF_tbl_billing_codes_invoice_text] DEFAULT -- Text was encrypted,
Regards.
Ken