Comments
Sort by recent activity
Brian,
That is incorrect. The problem was not related to a conflict or uncomitted changes. There were no conflicts and everything was checked in.
The problem was that when I created the migration script, I had to link it to "Uncommitted Changes" and tie it to specific objects and then commit them all at once. It would not work if I linked the migration script to "Specific Changes" (changes I had already checked in). So it seems SQL Compare will not recognize migration scripts that were linked to "Specific Changes" when they were created/committed. / comments
Brian,
That is incorrect. The problem was not related to a conflict or uncomitted changes. There were no conflicts and everything was checked in.
The problem was that when I created the migration s...
I started over so I could tie the migration script to "Specific Changes" (the tables, functions, data, and sprocs). But now SQL Source Control won't let me check in the items - I get this error: TF10141: No files checked in: resolve the conflicts and try again.
So until I can figure out that problem, I can't continue with my work-around attempt. / comments
I started over so I could tie the migration script to "Specific Changes" (the tables, functions, data, and sprocs). But now SQL Source Control won't let me check in the items - I get this error: TF...
Well, it took me quite a bit of work to get everything back to a clean state (fix the TF10141 error) but I did. I was then able to link my migration script to "Uncommitted Changes" so I could tie it to 3 specific objects. After I did that, then SQL Compare detected the migration script as desired. So the root issue appears to be: In order for SQL Compare to detect the migration script, it seems that the script must be linked to specific object(s) via "Uncomitted Changes", not a pre-committed change (i.e. "Specific Changes").
I don't remember seeing that in any of the examples or tutorials and it makes me wonder what the purpose is for creating a migration script against "Specific Changes" if the compare process won't see it. Maybe this is a bug? Or more likely I just don't fully understand the process yet. / comments
Well, it took me quite a bit of work to get everything back to a clean state (fix the TF10141 error) but I did. I was then able to link my migration script to "Uncommitted Changes" so I could tie i...
Root Cause - no work around:
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]. @SERVERNAME so even though they are different servers and SSMS sees them that way, SQL Source Control thinks it is the same server. @SERVERNAME which seems a little too risky. / comments
Root Cause - no work around:
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 ...
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! / comments
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/sugge...
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? / comments
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...
S...
I used SQL Packager to deploy to the [ServTest] server. So basically a packaged script. Does that help any? / comments
I used SQL Packager to deploy to the [ServTest] server. So basically a packaged script. Does that help any?
Thanks for posting this. We use lots of indexes with included columns so the documentation is very confusing. I also look forward to seeing a fix. / comments
Thanks for posting this. We use lots of indexes with included columns so the documentation is very confusing. I also look forward to seeing a fix.
I have version 1.1.0.19 (trial), but the history still shows the whole database even when I right click on a specific object in Object Explorer. I thought this was fixed - or am I misunderstanding? / comments
I have version 1.1.0.19 (trial), but the history still shows the whole database even when I right click on a specific object in Object Explorer. I thought this was fixed - or am I misunderstanding?
An easy way (UI) to associate the check-in with a work item is a must for us (we have not bought yet, just evaluating). The #A1234 hack helps, but is easy to forget and doesn't cover everything. TFS can be set up to require certain things like a work item, code reviewer, and other "Check-In Notes". SQL Source Control ignores all those requirements now which in turn generates "Policy Failure" alerts to our tech leads. We really need the tool to support this. A simple search or list would be nice.
FYI - the workspace issue (not getting to pick a workspace or its location) is the other big deal breaker for us (probably more so than the work item issue). Shelving would be nice, too. Other than that, we love it so far. / comments
An easy way (UI) to associate the check-in with a work item is a must for us (we have not bought yet, just evaluating). The #A1234 hack helps, but is easy to forget and doesn't cover everything. TF...