Comments
2 comments
-
Hi there,
With regards to your blocked issue, I have managed to replicate this on my machine. From what I can see, when you have a transaction running on the DB for the ALTER TABLE ALTER COLUMN statement, SQL Compare hangs and stops functioning due to the lock on the table.
Until the lock is cleared, SQL Compare will not finish whatever it's trying to do (in my testing I was just trying to compare my two databases) and will not produce any logs related to the hanging as it hasn't actually produced any errors.
I did do some testing around your link where it doesn't like the OBJECTPROPERTY() function, which you are correct on, but, various other portions of the query are also having issues running due to the lock. Specifically the 'definition' column in the sys.sql_modules table. It hangs when this is queried. As this issue is related to the table lock, there isn't anything else that can be done apart from clearing the lock to let SQL Compare function normally.
-
Kurt, thanks very much for the detailed response!!! Given that you've been able to confirm that the deadlock behavior would happen regardless, I am happy to let things lie as they are ... the tool, as usual, is doing its job well.
Thanks again!
Add comment
Please sign in to leave a comment.
While that's running, there's a blocked SPID (program_name = 'Red Gate Software - SQL Tools') that's attempting to run this statement on the same database:
It doesn't look to me as if the query really needs to know what the column data type is, so I'm guessing this is just due to the use of the OBJECTPROPERTY() helper function: see Bad habits: Using (certain) metadata "helper" functions (sentryone.com).