"Get Latest" problems - must unlink/relink database

AdamY

I am using SQL Source Control v2.0.10.11 and my source control system is TFS.
I have a database called [MyDB] on servers [ServDev] and [ServTest]. [ServDev] is the 1st phase of development and [ServTest] is where we deploy changes that are ready for testing. I linked [MyDB] to source control while viewing it in [ServDev] (in SSMS). After deploying [MyDB] to [ServTest], I noticed it is also linked to source control automatically (not what I'd like to happen, but I'll post a different thread about that).

Making changes in the [ServDev] database and checking them into Source Control is working fine. However, I can't seem to get "Get Latest" to work as I expected.

It seems I should always be able to do a "Get Latest". In other words, I should always be able to use the version of an object from Source Control and overwrite the version I have in the database. This method works well when promoting code from [ServDev] to [ServTest]. I expect to just make changes on [ServDev], check them into Source Control, and then do a "Get Latest" on [ServTest].

However, my "Get Latest" tab always shows "No new changes in source control" when I know for a fact that is wrong. I just checked in a change on [ServDev] that is in source control, but not on [ServTest] yet yet. If I "unlink database", then relink the database, the "Get Latest" tab will now show the changes I want to make. But if I click around too much and come back to the "Get Latest" tab, the changes no longer show and I have to go through the process again.

Is this a bug? Am I doing something wrong?

James B

This doesn't sound right. And regarding your other post- that doesn't sound right either.

How did you deploy the database to the SrvTest? It sounds like somehow the information on your machine about the two databases is one and the same - so that's why it looked like it autolinked, and also why when you checked in changes, it thought it was up to date.

The normal method of working is as you describe, you check in changes from one DB, and you can then "Get" those on another. So something sounds a little wrong here.
Can you clarify the process you took?

AdamY

I used SQL Packager to deploy to the [ServTest] server. So basically a packaged script. Does that help any?

AdamY

I realized there is a special setup that probably affects all this. The server names are actually the same, but in different networks (virtual). I use hosts file entries to connect to each. So...

Server names are both: [ServerA]
The IP for [ServerA] in the Dev network is 1.1.1.1
The IP for [ServerA] in the Test network is 1.1.2.1
My hosts file links 1.1.1.1 to [ServDev] and 1.1.2.1 to [ServTest].

Then, within SSMS, I just connect to [ServDev] or [ServTest]. I assume SQL Source Control thinks I am connected to the same server even though they are really different and look different in SSMS. Is there anything I can do about this?

James B

I think the identical server names are almost certainly the cause of what you're seeing. I'm not sure myself what mechanism SQL Source Control uses to work out the server it's connected to, but I'll check and see if there's any potential workaround.

James B

@SERVERNAME. This is so that you can connect via an IP/Name/Alias and still get consistent behaviour.

If using differently named servers is impossible, the only potential workaround is to work in different Windows logins for each database, as the information for the connections is held within your user profile - it's not ideal but I thought I'd suggest the option anyway.

AdamY

FYI for anyone reading this thread. I opened a feature request on the SQL Source Control forum. You can read it and vote for it at:
http://redgate.uservoice.com/forums/39019-sql-source-control/suggestions/2334790-force-get-latest-even-when-tool-thinks-there-are

Thanks!