Sql Schema Compare will not update after CLR object installed 'Source schema drift detected'

Question

After installing a custom CLR object Sql Server Developer Tools (SSDT) VS2012 will not allow an update. The error is \"Source schema drift detected. Press Compare to refresh.

Answer 1

This is not an answer but a clue to deal with this problem.

I was to update a colum from varchar[200] to varchar[MAX] and got this problem as well. So I logged in the server and tried to update the database manually via SQL Management Studio which was installed there, and I got this error:

"Saving changes is not permitted. The changes you have made require the folloing tables to be drpped and re-created. You have either made changes to a table that can't be re-created or enable the option Prevent saving changes that require the table to be re-created."

Seems that re-creating table is something so dangerous that "block/unblock on possible data lose" cannot handle. So I think only if we can walk around this LOCAL warning, could we update the database REMOTELY.

But, why [200] to [max] leads to re-creating table? It does not make any sense. I tried [200] to [1000], and it did not work as well. This might be the key to this problem.

And, if you do the same update in Server explorer in VS, instead of SQL Management Studio, it works. Again, why?

Answer 2

This sort of loop can also be caused by a referenced SSDT project failing to build. The referenced project may be missing, unloaded, or have an error which prevents the compare from completing.

Answer 3

I tried running VS as an administrator, it worked.

Answer 4

This can happen when a db user "changes".

The following rather scary forum page recounts issues where foreign hackers were trying to brute-force access to the "sa" db user, with each attempt changing the sa-user's date timestamp (which is seen as a schema drift):

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/5c22a7b4-7a82-4717-a118-2475bc62705b/schema-compareupdate-error-target-schema-drift-detected?forum=ssdt

Here is also mentioned that you can query the sa-user a few times, to see if this is happening to you:

SELECT * FROM sys.server_principals WHERE principal_id=1

I am currently experiencing the same issue (that the sa-user is being modified; I know nothing about hackers yet) and am yet to find a solution.

Edit - I turned on logging in Windows Firewall via properties > logging, and we setup a blocking rule on port 3071, which had a lot of unexplained traffic. Then the problem went away.