Comments
Sort by recent activity
I am working on a project where the results seem to be very similar. There are several assemblies that are registered in both the source and target dbs. Some are third-party, some are custom in-house code. All are set to run unsafe (file manipulation and de/encryption).
Anyway, now we move on to the interesting part. After reading this and other threads, I tried deleting the unsafe threads from the destination and the compare is SUCCESSFUL!!!
We are in the process of recovering a customer facing server and the inability to certify the completeness of the db has had me a bit "concerned". I guess I have come to rely on the SQL Compare tools as a certification method as well as deployment and troubleshooting.
So, deleting the assemblies from the target db seems to have resolved this issue. We had gone through much trouble of setting up asymmetric keys, logins, and users to be able to run .Net assemblies unsafe without having to resort to "trusted" settings at the db level.
Oh, and I was getting the same results ("index was outside the bounds of the array") regardless of the version of SQL Compare (v5 or v6 latest build in trial mode).
I hope this helps someone somewhere. / comments
I am working on a project where the results seem to be very similar. There are several assemblies that are registered in both the source and target dbs. Some are third-party, some are custom in-h...