SSC3 doesn't generate DROP statements?
dwainew
Posts: 59 Bronze 4
Using SSC 3.8.11.103
Any advice would be greatly appreciated... :?
If the purpose of SSC3 is to capture and allow the perfect duplication of the end shape of a DB from TFS, then shouldn't it at least offer the option to drop objects that are in the target, but not the source (Drop DB or TFS)?
I'm not seeing this happening with SSC3 in my environment, so I think I'm either missing an option or a basic concept. This is how SQL Compare works Live DB to DB, but not DB to TFS. It WILL generate SQL drop statements based on a compare to TFS, but there seems to be no way to remove the deprecated object definitions from TFS. (Or, preferably, change the object definition to an IF EXISTS DROP to keep it's previous history?)
Shouldn't the SSC3 COMMIT CHANGES tab offer to either remove or alter the definition to a drop for object in TFS but not the DB?
At the very least, it seems that SSC3 should NOT show a DB with the sync icon if there are objects in TFS that are not in the DB.
Thanks
Any advice would be greatly appreciated... :?
If the purpose of SSC3 is to capture and allow the perfect duplication of the end shape of a DB from TFS, then shouldn't it at least offer the option to drop objects that are in the target, but not the source (Drop DB or TFS)?
I'm not seeing this happening with SSC3 in my environment, so I think I'm either missing an option or a basic concept. This is how SQL Compare works Live DB to DB, but not DB to TFS. It WILL generate SQL drop statements based on a compare to TFS, but there seems to be no way to remove the deprecated object definitions from TFS. (Or, preferably, change the object definition to an IF EXISTS DROP to keep it's previous history?)
Shouldn't the SSC3 COMMIT CHANGES tab offer to either remove or alter the definition to a drop for object in TFS but not the DB?
At the very least, it seems that SSC3 should NOT show a DB with the sync icon if there are objects in TFS that are not in the DB.
Thanks
Comments
SQL Source Control does a three-way comparison between your database and two internal copies known as the transient and the working base - see here for more information. It will let you perform a drop, but unless you dropped it while the database was linked to source control, it won't know that a drop was performed. What you can do is retrieve the object using the get latest tab, then drop it and SQL Source Control will recognise the drop - you'll then see the drop appear in the commit tab.
Does that help?
Redgate Software
The page you've called out helps me understand why the app is working the way it does, but not how to use it in the wild. The real question is how to get the truth into TFS. What's the workflow?
I'm used to being able to tell source control what the truth is based on my knowledge of the state of the project, not having the tooling dictate which direction information can flow. This is probably me not having that ah-ha moment of understanding, so please, set me strait!
Using the page you've referenced as an example, I'd like to call out the moment I start to stumble...
If we compare Amanda's database and the scripts folder in source control, we can see a table in Amanda's database that isn't in source control. We don't have any information about where the difference came from, so we can't tell whether we should commit that table to source control or drop it from Amanda's database.
Shouldn't it be up to AMANDA what to do with the table? She's the dev and knows what her intent is. The table should show on both the commit tab as an add (to push the table to SCS) AND the get latest tab as a drop from the database.
my situation is this....
Amanda commits the table from her local db to TFS and labels this as v1.
Amanda is informed by the master of her universe that v2 now lives on server xyz. (v2 is actually an empty db, so the table isn't there)
Amanda opens SSMS and links xyz.db to the same TFS node with the intent of checking in v2.
To her surprise, SSC shows (by way of the icon in object explorer) that there are no differences! The commit tab shows nothing. Are v1 and v2 identical? Out of curiosity, Amanda views the Get latest tab and sees that there IS A DIFFERENCE between the DB and TFS that was otherwise unknown to her and SSC is offering to add the table to the v2 db.
What should Amanda do? She knows the new db is the truth, but can't check it in because SSC is only offering to go from TFS to DB.
Amanda is now managing 100 databases, each with thousands of objects and is put in the same situation...
Your suggestion of retrieving the missing objects (CHANGING the current truth), then dropping it (using what as a guide, a screen shot or a had written list?), simply to allow SSC to get its bearings is untenable in a situation where there are potentially hundreds of objects to process.
WHEN a DB is linked to a TFS node (or to what node) should have no bearing on the ability of the tool to capture the current shape of the DB in your source control system.
I'm really curious what the answer to this is. If you have an older version in a DB linked to TFS and a newer version in another DB, the best workflow I can think of (which isn't very appealing) is using SQL compare to sync the new db to the old and then use SSC to check in.
I don't understand why the physical action of a drop against a currently linked db is required to check in the absence of an object.
Thanks for your feedback. If you'd like to suggest that this behaviour is changed, then I recommend that you post it on our User Voice site - https://redgate.uservoice.com/forums/39 ... ce-control
Thanks.
Redgate Software