Changeset progress stopped by SQLCompare CPU race
dwainew
Posts: 59 Bronze 4
I've gotten about 10 db's into VSS using changeset without incident. My latest attempt was a fairly large schema with about 1200 or so objects. I was following the typical pattern.
use compare to script out the DB to a script folder, Create a new compare project comparing the folder and live DB, identical, of course. Edit the compare project, click "register folder" and match up the script folder with a new VSS project folder. After registering the folder, changeset took a few minutes to compare and come up with all the adds required. select all, give a comment and click commit. Everything normal up to now.
Sometime through the commit process, I noticed the changeset dialog box was stuck on the same file for quite some time and my CPU was pretty sluggish. It turns out, looking at task manager, that the SQLCompare UI process was racing!? Of course compare isn't required during this stage, so I closed out of the compare project properties dialog, all the way out to closing SQLCompare without issue. At this point, changeset happily started working again without issue.
looks like SQLCompare was doing something in the background that conflicted with changeset's check-in process?
use compare to script out the DB to a script folder, Create a new compare project comparing the folder and live DB, identical, of course. Edit the compare project, click "register folder" and match up the script folder with a new VSS project folder. After registering the folder, changeset took a few minutes to compare and come up with all the adds required. select all, give a comment and click commit. Everything normal up to now.
Sometime through the commit process, I noticed the changeset dialog box was stuck on the same file for quite some time and my CPU was pretty sluggish. It turns out, looking at task manager, that the SQLCompare UI process was racing!? Of course compare isn't required during this stage, so I closed out of the compare project properties dialog, all the way out to closing SQLCompare without issue. At this point, changeset happily started working again without issue.
looks like SQLCompare was doing something in the background that conflicted with changeset's check-in process?
Comments
The other thing is that you may have a hidden window. Sometimes there are some windows which pop up from source control but are hidden behind SQL Compare, and they need user input so you cannot see them. There is a section about it in the help file:
"SQL Changeset is not responding
Your source control system may display a message box (such as an error notification) or an authentication dialog box behind your current windows; this gives the appearance that SQL Changeset is not responding. Unfortunately, due to the interface provided by the generic source control API, SQL Changeset is unable to access or process these message boxes.
To proceed, you must use Alt+Esc to access the message box, and then clear it, for example by clicking OK. Refer to your source control system documentation for more information on specific errors or messages."
Red-Gate support
The odd thing is that Task Manager would report high CPU from the SQL Compare UI process. Changeset does all the communication with the source control system, and only interacts with SQL Compare through a remoting channel which is basically used to send commands to changeset (like get latest version before comparing, etc).
We can't visualize a situation where a hanging Changeset process can affect SQL Compare, though...