Posted: Thu Mar 10, 2005 2:24 pm Post subject:
Thanks for letting us know about this problem.
We had already spotted this and have fixed it. The fix will appear in the next minor release of the product which will be released shortly.
, which is not true since this info is available in objectpropertyex(sp?), and the SQL Compare already appears to ask the question at the beginning of a run - ( if there are no encrypted objects, then don't use the traceflag code route - even if that behavior is turned on ). What you were probably trying to say is that : SQL Compare has no way to find the encrypted objects within the pages on disk, so takes the approach of reading from every page in a manner which requires the use of the Trace flag. Are you telling me that's absolutely necessary? I'm no expert on internals but it seems to me that with 2005 and 2008 there was a lot more disk if not page level info given. Even if it wasn't, I doubt that the 'name' ( however it works at that level ) is encrypted. Couldn't you find some way to identify only the objects whose pages need to take the trace flag route in your code? Again, if you're asking me why this is important, see my original post, then try running SQL Compare against an instance of Microsoft Dynamics Great Plains. Once with and once without decryption set to on. And if you're gonna tell that joke "so the doctor says, Don't move your arm that way and it won't hurt", please see my third question. One of my tasks is to take snapshots of the db schema every so often and if there is no answer to my third question, it means I am damned to extremely long scripting times.SQL Compare does not know which objects are encrypted
Users browsing this forum: Bing [Bot] and 0 guests