"Get Latest" problems - must unlink/relink database

A SQL Server Management Studio add-in to source control your database in Subversion or Team Foundation Server.

Moderators: Chris Auckland, David Atkinson, sherr, PhilScrace

"Get Latest" problems - must unlink/relink database

Postby AdamY » Fri Mar 11, 2011 10:57 pm

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?
AdamY
 
Posts: 41
Joined: Fri Oct 15, 2010 8:24 pm

Postby james.billings » Mon Mar 14, 2011 7:47 pm

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?
james.billings
 
Posts: 1144
Joined: Wed Jun 16, 2010 11:10 am
Location: My desk.

Follow-up

Postby AdamY » Mon Mar 14, 2011 11:02 pm

I used SQL Packager to deploy to the [ServTest] server. So basically a packaged script. Does that help any?
AdamY
 
Posts: 41
Joined: Fri Oct 15, 2010 8:24 pm

More follow-up.

Postby AdamY » Mon Mar 14, 2011 11:14 pm

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?
AdamY
 
Posts: 41
Joined: Fri Oct 15, 2010 8:24 pm

Postby james.billings » Tue Mar 15, 2011 2:22 pm

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.billings
 
Posts: 1144
Joined: Wed Jun 16, 2010 11:10 am
Location: My desk.

Postby james.billings » Tue Mar 15, 2011 3:00 pm

Following up on my last post- as I suspected, we don't use the SSMS connection to establish the name, but instead we query the server using SELECT @@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.
james.billings
 
Posts: 1144
Joined: Wed Jun 16, 2010 11:10 am
Location: My desk.

Enhancement request

Postby AdamY » Thu Oct 20, 2011 11:25 pm

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!
AdamY
 
Posts: 41
Joined: Fri Oct 15, 2010 8:24 pm


Return to SQL Source Control 2

Who is online

Users browsing this forum: No registered users and 0 guests

cron