SQL compare stops to compare on 42% (reading dependencies)

Compares and synchronizes SQL Server databases, backups and scripts.

Moderators: JonathanWatts, Chris Auckland, David Atkinson, eddie davis, Anu Deshpande, Michelle Taylor, alice.easey, james.billings, chengvoon.tong

SQL compare stops to compare on 42% (reading dependencies)

Postby Bertoz » Wed Mar 21, 2012 12:59 pm

Hi guys...
I do the normal daily comparing but today SQL Compare stops the comparing at the 42%, when it's reading dependencies... and I can't do anything anymore, just kill the process.
Any idea ?

Thank you in advance.

Nick[/img]
Imagination is more important than knowledge
Bertoz
 
Posts: 3
Joined: Wed Mar 21, 2012 12:46 pm
Location: Tenerife

Postby Brian Donahue » Fri Mar 23, 2012 5:17 pm

Hi Nick,

Typically, programs do not just stop working. When Windows shows a "not responding" message, it usually just means there is a long-running function and usually you can just "wait it out". Unfortunately I do not know of an option that will speed this up.

If it never responds after an unreasonable amount of time (depending on the size of the database) , then we can try debugging it to make sure the worker thread reading dependencies has not been aborted for some reason.
Brian Donahue
 
Posts: 6670
Joined: Mon Aug 23, 2004 10:48 am

Re:

Postby Bertoz » Fri Mar 23, 2012 5:45 pm

Hi Brian.
I let the program run for more than 1 hour, and usually the comparing takes less than 10 seconds... I don't know if this amount of time is reasonable, I don't think so.

Anyway the program is working now.
I have no idea what happened that day.
Checking the log, I realized that the night before there was a problem with the process of stats updating of sql server.
I suppose this is in some way related, because the day after, with the stats updating successful, the program restarted to work regularly.
I'd like to understand what happened in order to avoid this problem in the future.
Thank you for your answer.

Nick
Imagination is more important than knowledge
Bertoz
 
Posts: 3
Joined: Wed Mar 21, 2012 12:46 pm
Location: Tenerife

Postby Brian Donahue » Fri Mar 23, 2012 6:40 pm

I guess SQL Server just had a lock on the information schema. Sounds like a possibility from what you've said...
Brian Donahue
 
Posts: 6670
Joined: Mon Aug 23, 2004 10:48 am

Re:

Postby xerxxees » Tue Apr 17, 2012 4:33 pm

Brian Donahue wrote:I guess SQL Server just had a lock on the information schema. Sounds like a possibility from what you've said...


I have a similar issue. When I run SQL Profiler at the same time I see the following command repeating over and over:
SELECT revisions.value AS Revision, scripts.value AS ScriptsLocation, migrations.value AS MigrationScriptsLocation
FROM [cmbs].sys.extended_properties AS revisions
JOIN [cmbs].sys.extended_properties AS migrations
ON migrations.minor_id = revisions.major_id
JOIN [cmbs].sys.extended_properties AS scripts
ON revisions.minor_id = scripts.minor_id
WHERE revisions.name = 'SQLSourceControl Database Revision'
AND migrations.name = 'SQLSourceControl Migration Scripts Location'
AND scripts.name = 'SQLSourceControl Scripts Location';

We have a fair amount of databases of various sizes over the years and they've all run great. A possible difference is that this database is larger then the others and I recently upgraded to SQL Compare 10.

Any ideas why that command would repeat over and over?
xerxxees
 
Posts: 1
Joined: Tue Apr 17, 2012 4:29 pm

Re:

Postby Bertoz » Tue Apr 17, 2012 4:42 pm

xerxxees wrote:
Any ideas why that command would repeat over and over?


I don't know why but now I know how... When SQL Compare goes in loop I detach the DB and then I attach it again. Luckily I got problems only with the Test DB...
Imagination is more important than knowledge
Bertoz
 
Posts: 3
Joined: Wed Mar 21, 2012 12:46 pm
Location: Tenerife

Postby Brian Donahue » Tue Apr 17, 2012 5:11 pm

This is a different issue. The stuff the SQL Compare team added for migrations includes a few extended properties in the database. Once SQL Compare determines that database has been processed by SQL Source Control, it continually polls the database.

This doesn't have anything to do with the program locking up during a comparison (I don't think).
Brian Donahue
 
Posts: 6670
Joined: Mon Aug 23, 2004 10:48 am


Return to SQL Compare 10

Who is online

Users browsing this forum: No registered users and 0 guests