Red Gate forums :: View topic - "Get Latest" problems - must unlink/relink database
Return to www.red-gate.com RSS Feed Available

Search  | Usergroups |  Profile |  Messages |  Log in  Register 
Go to product documentation
SQL Source Control 2
SQL Source Control 2 forum

"Get Latest" problems - must unlink/relink database

Search in SQL Source Control 2 forum
Post new topic   Reply to topic
Jump to:  
Author Message
AdamY



Joined: 15 Oct 2010
Posts: 37

PostPosted: Fri Mar 11, 2011 10:57 pm    Post subject: "Get Latest" problems - must unlink/relink database Reply with quote

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?
Back to top
View user's profile Send private message
james.billings



Joined: 16 Jun 2010
Posts: 1123
Location: My desk.

PostPosted: Mon Mar 14, 2011 7:47 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
AdamY



Joined: 15 Oct 2010
Posts: 37

PostPosted: Mon Mar 14, 2011 11:02 pm    Post subject: Follow-up Reply with quote

I used SQL Packager to deploy to the [ServTest] server. So basically a packaged script. Does that help any?
Back to top
View user's profile Send private message
AdamY



Joined: 15 Oct 2010
Posts: 37

PostPosted: Mon Mar 14, 2011 11:14 pm    Post subject: More follow-up. Reply with quote

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?
Back to top
View user's profile Send private message
james.billings



Joined: 16 Jun 2010
Posts: 1123
Location: My desk.

PostPosted: Tue Mar 15, 2011 2:22 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
james.billings



Joined: 16 Jun 2010
Posts: 1123
Location: My desk.

PostPosted: Tue Mar 15, 2011 3:00 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
AdamY



Joined: 15 Oct 2010
Posts: 37

PostPosted: Thu Oct 20, 2011 11:25 pm    Post subject: Enhancement request Reply with quote

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!
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic All times are GMT + 1 Hour
Page 1 of 1

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group