I am trying to generate a Snapshot of a database located in a remote location. I am runing SQL Compare 10.3.

I have verified that SQL Compare has no trouble in seeing that server (and the database). The tool can successfully retrieve the list of the databases on the SQL Server Instance when connecting to it.

Having said that, either when trying to run a comparison project (or when generating a snapshot) the tool is stuck at a step called "Reading object text" (which in the case of the snapshot is around 29% for my database).

I let it run for an hour and it has not been progressed by a single percentage so at this point I believe the process is stuck. I have tried twice and in both cases it got stuck at the precise same location.

I have a print-screen of the exact state where the tool get stuck but I believe there is no way to add attachments to post here.

I believe this is a bug that for some reason only occur under this circumstance but even when the behavior (the error) is consistently happening, I can't figure out why it happens or what should I do to fix it.

If anybody in the forum supports that tool (or has seen the error before) please let me know what you think I should be doing in order to troubleshoot.

I can confirm the same behavior. When registering the SQL database, SQL Compare 10.7 gets stuck at "Reading object text" on a large and complex database. Running sp_who2 against the database shows that the SPID is "SUSPENDED".

Checking the logs, I see:
Populate ObjectText start.
Remembered which version of System.Data.SQLite is in use: System.Data.SQLite, Version=1.0.85.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139

Then, nothing.

Interesting: this database is about 250GB. A database with a similar schema but not data on the same server registers just fine.

Update: I ran a Trace and I see that SQL Compare is executing DBCC PAGE commands while the interface is unresponsive.

An update: I found the reason for the performance difference. The large database had a single encrypted object (a 5-line stored procedure), and the option to decrypt encrypted objects was checked (it is checked by default). Unchecking the option to decrypt encrypted objects solved the performance issue.

fllouw wrote:An update: I found the reason for the performance difference. The large database had a single encrypted object (a 5-line stored procedure), and the option to decrypt encrypted objects was checked (it is checked by default). Unchecking the option to decrypt encrypted objects solved the performance issue.

Thanks, Francois

Thanks fllouw, that also fix the performance problem in my case as well. Now the only question that remains is why option to decrypt encrypted objects causes so much overhead, but that is a question I will leave for another day.