Settings and activity
3 results found
-
3 votes
An error occurred while saving the comment 
Dwaine Wright
shared this idea
·
-
58 votes
An error occurred while saving the comment Dwaine Wright
commented
Wow, I didn't even notice this until I read the post!!!
First, I'm concerned that you've added the comment "Used by SQL Source Control – do not modify" to each workspace. Please explain. It it means what it says, that's bad form in my opinion. Once code is in TFS, why would a workspace matter at ALL? I'd like to delete them all! Are you suggesting that would break SSC functionality? You aren't even working inside of VS!? If my dev machine died and I had to build from scratch? A new dev starting from scratch and pulling the branch... they have no worksapce to start with.
Second, I'm confused, why even use a workspace? AFAIK, TFS workspaces should be defined and controlled by the user, NOT a TFS client. The SQL folder/file structure should live under and play nice using the same model. If you need a scratch area, you have at your disposal USER\AppData\ or ProgramData, which are the only appropriate places an app should save data as per industry standards. Please explain.
Dwaine Wright
supported this idea
·
-
8 votes
An error occurred while saving the comment Dwaine Wright
commented
It is really surprising that this only had one vote. The basic concept is this, redgate has been doing this a long time, and their tools rock, but they've also been mired in a database-centric mentality. That was fine when SQL compare (and even SQL Source Control) was new, but there needs to be a more "instance-centric" or even "enterprise-centric" shift in paradigm. How many enterprise applications use only one database, or even only one instance? The solution suggested by the OP has been sorely needed for years. Years ago, I used the SDK to roll my own console app to implement an enterprise "version monitor" by simply enumerating servers and their databases, dumping snapshot files named by Instance-DB-Timestamp or comparing the DB to the most recent file, generating a new file if any changes were detected. A GUI based app that would provide a similar configured 5000 foot view would be outstanding. DLM dashboard (haven't had time to evaluate it yet) is a server / DB based solution that is overkill for what's being asked. The concept of simply extending SSC and/or SQL Compare projects to support a file based solution approach should be strongly considered.
Dwaine Wright
supported this idea
·
(sorry, visual cue)...
COMMIT CHANGES Should offer to DELETE missing objects from TFS, and GET LATEST should offer to generate DROP statements to remove unwanted DB objects!
It seems even worse than I thought! I can't use either SQL compare OR SQL Source Control to remove deprecated items from TFS? SSMS can only generate a script to remove them from the DB, and SSC will only add the unwanted objects to a DB, no way to remove what's not wanted from TFS. I have only 28 objects.... What if I had 1,000??!! is this a bug in 3.8.11.103 or am I missing something basic?