Show History Very Slow

skuhn · December 30, 2011 11:02AM

I have the latest version of SQL Source Control, 3.0, (in SSMS 2008 R2) linked to SQL Server 2005 databases and a SourceGear Vault 5.1.1 repository. The SQL Server instance in question has 6 databases linked, however I am only opening one database that has 4 tables and 1 stored procedure. When I right-click the database and choose Show History, the History dialog comes up but sits there with a message that says Waiting for other operations to complete. It's not clear what those other operations are but after 10 minutes I give up. After that I am unable to close SSMS as it indicates that there are processes running.

Could this be Sql Source Control checking for differences in all of the linked databases in the background? (The swirl is not showing on the other databases that I have not opened.)

James B · January 2, 2012 7:55AM

Thanks for your post. I don't believe it should try to access other databases if you've not selected them in the object explorer, so it's a little strange.

Does the problem affect all users/databases? Or does it only seem to occur on your own machine? Have you tried unlinking and re-linking the database to see if it helps at all?

skuhn · January 3, 2012 10:55AM

I did unlink and relink and that seemed to have resolve the issue temporarily. Now, whenever I commit changes, it appears that there is a disconnect between the version that SQL Source Control is expected and what our Vault repository is returned. It's expecting 2362 but 2363 was returned. (Numbers not actual, but vault is returning one version beyond what SSC is expecting.)

Now, after every commit changes, I have to unlink and relink to clear the issue.

I'll have to have another member of the team try to commit changes to see if similar issues are observed.

James B · January 3, 2012 11:02AM

Thanks for your reply - please do update us with what the other team members see. I didn't think the revision number was something we particularly cared about (we'd presumably grab whichever number is returned back from the server). What's the exact error it gives you in that area? Is it one with an option to submit an error report to us at the bottom?

skuhn · January 3, 2012 11:30AM

The error is as follows:

Vault's cache hasn't been updated with the commit details

Expected 27953 actual 27954

.. and yes it gives me the option of submitting an error report to Red Gate. (Which I have done.) Note that after this I sometimes get a second error after waiting a long time for the Commit Changes tab to update. It seems to cycle through the 4 steps several times and then I get the error that indicates that the action failed after 5 tries, which also gives me the option to send the error to Red Gate. (Which I have also done.)

On the occasions where I get the second error, I have to unlink and relink the database to clear up the issue; which returns again once I commit changes.

Will provide results from other team members shortly.

skuhn · January 3, 2012 3:34PM

Hmm...I had one of my co-workers attempt to make a change and commit it and they see no errors like I do. It appears to be an issue that only I am experiencing; which is odd because unlinking and relinking does not permanently resolving the issue. Is there something else I need to perform to clear out whatever settings SQL Source Control has for the database in question?

James B · January 3, 2012 3:50PM

If a relink doesn't help, then it shouldn't be a problem with your local files as these would be refreshed.

Next time the error occurs, can you click the "send error report" link at the bottom, and ensure you enter your email addres? This may tell us a little more about what's happening.

skuhn · January 3, 2012 4:30PM

It appears that I have solved the issue. The fact that the error(s) were only occurring for me and the fact that an unlink/link did not solve it completely, I turned to Vault. It turns out that my Vault client cache was out of sync with the server. I cleared the vault client cache and now the problem is resolved.

Thanks for your guidance James; it helped me reach resolution.

James B · January 4, 2012 6:53AM

That's great to hear, and thanks for posting back your findings. Hopefully it'll help anyone else who runs into a similar issue!

skuhn · January 9, 2012 1:35PM

Actually, this is still an issue. We are looking to deploy changes to another database and when looking at the history through SQL Compare, the history window just sits there with the spinning green circle with the message "Waiting for other operations to complete".

James B · January 9, 2012 1:42PM

Sorry to hear that SQL Compare is now giving you trouble - is this on the same machine that you "fixed" SQL Source Control on earlier?

As a quick workaround, can you check out a copy of what's in the Vault repository to a local folder on the PC, then try SQL Compare against that, using the "Script Folder" option? If that works, then it suggests some difficulty with it talking to Vault, but if the problem persists, then it's more likely to be something strange in the files in your repository.

skuhn · January 9, 2012 7:28PM

Yes, this is the same machine. I tried to do a history in the vault client and found an issue with my local file storage. I resolved this issue but still have a problem with SQL Compare. I tried the compare against the local file store and it worked fine, so I expect that SQL Compare is having issues with Vault.

Additionally, if we simply do a compare to an "unchanged" database against the "head" revision of a branch in Vault, SQL Compare doesn't seem to pick up the need to use a migration script created through SQL Source Control, though we have created one. What, exactly, would cause SQL Compare to recognize that a migration script must be used and where to find it?

skuhn · January 9, 2012 7:47PM

Wait, I apologize, we were choosing the source control location incorrectly when SQL Compare did not recognize the need for a migration script. We figured that out. Again, sorry about the additional question.

mulmad · February 1, 2012 5:11PM

I'm having the same issue in my source control - source gear valut setup.

From the Vault client I have cleared the local cache and pulled all files from the server.

Everything else (that I've tried) in sql source control works really smoothly, however, I get the "Waiting for other operations to complete" when right-clicking a table, a view or any other source controlled object from the SMSS Object Explorer and select Show History

From the Vault client I have no trouble viewing history and differences.

any suggestions?

maturmel · April 10, 2012 12:07PM

Hi, not sure if I should try to revive this thread vs creating a new one, but I just had the exact same symptoms as initially posted here: Show History sits at the "Waiting for other operations to complete" for ages. I am running version 3.0.6.25, which seems is the latest to date.

When I give up the history dialog I also have the problem of SSMS process being stuck in execution. I have to kill the process from Task Manager and restart SSMS.

After killing the task and restarting, I went to do Show History on the same database again, this time it seems to be working its way through. It is still a slow process to bring up the history (especially "4/4 calculating changes", well over 20 minutes and still processing as I write this). But it was the very first SSC-related operation I did after restarting SSMS. It seems if you work for a while with the tool, at some point the Show History just gets stuck and stops working. I wish I could be more specific as to the circumstances or operations that can lead to this state, but for now this is all I have. I'm keeping an eye open on any piece of information worth sharing and will report back if anything comes up.

Thanks

Show History Very Slow

Comments

Product Learning

Community Forums

Events & Friends

Simple Talk