Is there a way to refresh the working base w/o unlink/link?

jeff.stanlick

Here's our scenario:

A developer is working with a database in dedicated mode using SSC version 2.2.1.23. They make changes to the database and commit them to our SVN repository. The production database backup is then restored to the server that developer is using overtop of the database they've modified. When they check the Get Latest tab it does not show the change they added to the SVN repository even though their change is not in the database. In their working base directory for that server, there is a copy of the SQL file that matches the SVN repository (which is why I'm guessing the Get Latest tab is not showing it as a difference).

Currently, we unlink the database and then link it again. This seems to create a new working folder and generate a new compare. Is there are way for us to tell SSC to rebuild the working base, or force it to update w/o unlinking and re-linking?

Thanks,
-Jeff

peter.peart

Thanks for your post. That doesn't sound ideal, but I have to admit I'm not entirely sure if there's a good reason for so I'll check.

What you can do go get around this is the following:

1) On the SQL Source Control setup tab, hold down SHIFT + CTRL and right click on the linked to path. This should then give you your working base location
2) In the working base, delete the offending files
3) Go back to the Get Latest tab, and you should be notified of conflicts and you can then Take theirs to update your systems

Out of curiosity, why is the Prod DB being restored in Dev? Is it to get up to date data?

Pete

jeff.stanlick

Over the course of 3 months we had made over 100 new objects and about 400 other object changes across 4 databases as part of a warehousing project. Unfortunately, for various business reasons, we couldn't deploy all of those changes at once. So, we deployed all of the new objects to the production environment and then we wanted to do more testing with a portion of the object changes. Before doing this we wanted our testing environment to look just like the production environment. We were relying on SSC to help us identify all of the objects that required changing. When none of them showed up our Data Architect freaked. He crawled back from the ledge after we relinked the databases on his machine and the differences showed up again.

With the volume of changes he was making, I'm not sure this workaround would be a lot better than unlinking and relinking his machine. But, it definitely seems better for just a handful of changes.

-Jeff

peter.peart

Ahh, I see. Well, I'll double check intended design and let you know.

And yes, in this scenario I can easily see how a link and re-link would be better.

Just so you're aware, something that might be handy for you is a free unsupported utility that someone in the support team put together. It searches for any unused working bases and then gives you the option to delete them en masse. It's available from the below link:

ftp://support.red-gate.com/utilities/SQ ... leaner.zip

Pete

jeff.stanlick

That does sound handy.

Thanks!
-Jeff

DavidRG

I'm one of the developers on SQL Source Control, and I just thought I'd explain a little more in depth what's going on.

When you restore the database backup (which essentially takes your local database back in time), SQL Source Control doesn't know that you've done that specific action. All it knows is that your local database has been changed. Therefore, the retrieve tab will be empty (as you observed, because the SVN repository hasn't changed, so there's nothing to retrieve), and the commit tab will show all the changes that restoring the backup has made to the database. These changes can then be committed (on the commit tab), or undone (on the undo dialog). Alternatively you can unlink and relink which will give you a new "Working Base", with the effects that you observed.

If you just want to see the differences the commit tab is the easiest way to do it, but it's very confusing to look at (because the changes are the wrong way round). You can then use commit button to change the SVN repo to be the state of the backup, or you can use undo to change the database to be the state of the repository. Why both of these work is quite confusing UX though, so we recommend unlinking and re-linking.

The workaround Pete gave of deleting the offending files from the working base isn't quite right. Instead for step 2 you need to use TortoiseSVN to update the working base to the SVN revision that the database backup corresponds to. The reason why deleting the offending files won't work is that SQL Source Control will notice that they're missing, and automatically put the files back again, which isn't what you want.

jeff.stanlick

David,

I don't know why I didn't think of using Tortoise to update the local directories to the "older" version. That makes a lot of sense. We can do that.

Although, our Data Architect would like a button (or a context menu item) in SSC to tell it to rebuild the working base from the database :lol:

Thanks,
-Jeff

DavidRG

Cool!

Having a button/menu item to fix the working base is not something that's easy for us to do right now in v2, but for v3 we're planning to add an extended property to the database so that we know what revision it is at.

When you restore the backup, we could spot that the revision has gone back in time, and so fix the working base for you automatically, without a need for a button/menu item. I'll raise this with our product manager and see what he thinks. We're on a quite tight release schedule for v3, so if we do decide to do it, it'll be more likely to be done after that point, i.e. v3.1 at the earliest.