Comments
Sort by recent activity
We have a policy to require associating work items, but even when I attempt to associate a work item, I am getting a policy failure. I have to do an "ignorepolicies" and then go back and manually associate the changeset later. It is a hassle. / comments
We have a policy to require associating work items, but even when I attempt to associate a work item, I am getting a policy failure. I have to do an "ignorepolicies" and then go back and manually ...
VS 2010 Ultimate - 10.0.40219.1 SP1Rel
SSMS 2008 R2 10.50.1617.0
Don't know my version of TFS DLL. / comments
VS 2010 Ultimate - 10.0.40219.1 SP1Rel
SSMS 2008 R2 10.50.1617.0
Don't know my version of TFS DLL.
After upgrading to 3.1, SQL Source Control no longer seems to pick up changes that I am making to the db through SQL Management Studio. I have to restart SSMS in order for SSC to detect any changes. / comments
After upgrading to 3.1, SQL Source Control no longer seems to pick up changes that I am making to the db through SQL Management Studio. I have to restart SSMS in order for SSC to detect any changes.
I ran SQL Data Compare using my development database root folder from TFS that was created by SSC when I linked the database to source control as the source scripts folder and I used my staging branch root folder prior to merging from the development branch as the target scripts folder and SDC picked up the differences in the lookup table data. However, when I went to use the SDC synchronization wizard to generate the deployment script, I got an error saying that the "given key was not present in the dictionary". However, if I right-click on just the lookup table object in the comparison pane and select the "Show Object Synchronization Script", I get the script with no errors. If I can use this method to compare dev branch to staging branch as script folders I can probably automate some kind of short term work around to my problem, as long as the synchronization wizard doesn't error out. Otherwise I'm really going to have problems dealing with any static data changes to the database. It will be a maintenance nightmare. As another potential worka round, I tried using migration scripts to manually change the data myself, but I got a message saying that since there were no schema changes involved I couldn't even use a migration script. Please help me figure this out. This is a critical issue for us. / comments
I ran SQL Data Compare using my development database root folder from TFS that was created by SSC when I linked the database to source control as the source scripts folder and I used my staging bra...
Because at one point I could swear that it actually worked, but I had to launch SQL Compare from within SSMS on the source controlled database, and then I saw the linked data changes in the comparison output without having to go through SQL Data Compare (which I do remember never actually worked when using a SSC database as the source). So tell me again the best practice for deploying changes to static linked data? What is the purpose of linking it in SSC then? Wouldn't it just be better to write a migration script manually then? / comments
Because at one point I could swear that it actually worked, but I had to launch SQL Compare from within SSMS on the source controlled database, and then I saw the linked data changes in the compari...
why does ssc create so many workspaces in the first place? i noticed that ssc has created a large number of workspaces behind the scenes. at one point my default workspace for my source code accidentally got mapped to one of these workspaces and i inadvertently mapped it to my local folder. then i made some changes to code files in my solution and it turned out i had some code files checked out to my actual workspace and some code files checked out to this workspace. it took me quite a while to figure out was going on and later i had to reconcile quite a number of changes manually, which was quite a pain. is there a way i can prevent this from happening in future? / comments
why does ssc create so many workspaces in the first place? i noticed that ssc has created a large number of workspaces behind the scenes. at one point my default workspace for my source code acci...
I also am having difficulties identifying the best practices for branching/merging with SQL Source Control in TFS. I suspect it differs from the best practices for creating and working with code branches. Currently, we have 3 database environments: development, staging, and production. Mimicking the best practice that we use for version controlling our code files, I created a main folder in TFS and linked it to our staging database. I then created a development branch from within TFS off of the main (staging) branch. I then attempted to link the development version in TFS to our development database in SSMS using SQL Source Control. However, I got the error that "The path must be an empty folder." How then does SQL Source Control support branching/merging? Does it actually support branching/merging through TFS, and if so, how would branching/merging be accomplished? Do you have any white papers on this? Any help here would be greatly appreciated. / comments
I also am having difficulties identifying the best practices for branching/merging with SQL Source Control in TFS. I suspect it differs from the best practices for creating and working with code br...
Never mind. I figured out how to do this. I don't know why it was giving me this error before. After closing out of SSMS and then restarting it, I was able to link to my branched database. / comments
Never mind. I figured out how to do this. I don't know why it was giving me this error before. After closing out of SSMS and then restarting it, I was able to link to my branched database.