Comments
Sort by recent activity
We currently don't store the CREATE DB script in source control. So, you just need to create a new db first as you normally would. This way you can specify size and locations in case machines are different. Then link this new db to source control on the setup tab. (Use the "Link to a db already in source control..." instead of the "Create link" on the Setup Tab.) Then get latest, which will bring your new db up to date with everything that was in source control.
You can vote/comment on this feature request at http://redgate.uservoice.com/forums/390 ... ?ref=title. / comments
We currently don't store the CREATE DB script in source control. So, you just need to create a new db first as you normally would. This way you can specify size and locations in case machines are...
Hi Minh,
Were you able to exclude the SQL Source Control 0 folder from Microsoft Security Essentials live protection? If so, please let us know if you still expereince any problems when commiting a lot of objects.
Thank you!
Stephanie Herr :-)
SQL Source Control Project Manager / comments
Hi Minh,
Were you able to exclude the SQL Source Control 0 folder from Microsoft Security Essentials live protection? If so, please let us know if you still expereince any problems when commiting ...
This sounds like a problem we've seen before. Do you have Microsoft Security Essentials installed? If so, this could cause a problem when committing a large number of objects, which is usually the case when first committing an existing database to source control. Your workaround of doing a smaller partial commit seems to fit this expected behaviour.
To get around this, please configure Security Essentials to exclude %LOCALAPPDATA%\Red Gate\SQL Source Control 0\ from live protection. / comments
This sounds like a problem we've seen before. Do you have Microsoft Security Essentials installed? If so, this could cause a problem when committing a large number of objects, which is usually th...
We can provide some insight into why this is happening...
Each user is working directly on the same db and committing to source control from SSMS, but each user also has their own underlying working folder on the file system, which is NOT shared.
This "conflict" problem will occur if a user's underlying working folder is out of synch. This occurs if a user doesn't visit the commit tab when the db matches the latest version in source control. This means user 1 changes an object and commits it. User 1 then makes another change to the same object, but doesn't commit it yet. User 2 now visits the commit tab for the first time since user 1's initial commit. User 2 will see a conflict because their underlying working folder is out of date.
User 1 will never see a conflict because their working folder is in synch. Once user 1commits the table and user 2 revisits the commit tab, the conflict will disappear and both users' working folders will be in synch.
This probably explains why the conflict appears on your co-workers workstation and not your own. Were you the one that made changes to the object? Did you make changes commit and then make more changes?
We'd really like to know how many other people are experiencing this problem and how often you experience this problem. How serious is this problem for you? Would this prevent you from using SQL Source Control?
For now, please just ignore these conflicts if you are on a shared DB environment. It only means that there have been multiple changes to the same object since you last visited the commit tab. Once the user commits his/her current changes, the conflict should disappear for the other users.
I hope this makes sense. Our internal tracking number for this issue is SOC-854. / comments
We can provide some insight into why this is happening...
Each user is working directly on the same db and committing to source control from SSMS, but each user also has their own underlying workin...
Please vote/comment on this feature for SQL Source Control on our Suggestion Forum at http://redgate.uservoice.com/forums/390 ... ?ref=title / comments
Please vote/comment on this feature for SQL Source Control on our Suggestion Forum at http://redgate.uservoice.com/forums/390 ... ?ref=title
Emailed user directly to try and get a better understanding of what steps to take so we can try and reproduce this issue. / comments
Emailed user directly to try and get a better understanding of what steps to take so we can try and reproduce this issue.
Hi Graham,
Thanks for letting us know about this issue. We currently do NOT notify you if you rename a Primary Key. We will notify you if you alter a table and add a PK or drop a PK.
As soon as you go to the Commit list, we'll realize there is a change and put a blue indicator on the table.
David is right. We don't put blue indicators on nodes lower than the actual table. This is because the columns, keys, indexes, etc. get scripted in the same file as the CREATE TABLE script, which is in the Tables directory in source control.
Our internal issue number is SOC-816. / comments
Hi Graham,
Thanks for letting us know about this issue. We currently do NOT notify you if you rename a Primary Key. We will notify you if you alter a table and add a PK or drop a PK.
As soon as y...
Oops! You're right. I meant RC. I updated our internal issue to reflect this. :-) Thank you! / comments
Oops! You're right. I meant RC. I updated our internal issue to reflect this. :-) Thank you!
We are currently supporting TFS 2008. (There is minimal support for TFS 2005, but this hasn't been tested completely since most users seem to be on 2008.) So, SQL Source Control is looking for either the Team Explorer 2005 or 2008 Client.
We haven't tested against Visual Studio 2010 yet since that is still in beta, but we do plan to support that. Our internal issue reference number is SOC-804.
Thanks for providing us with the link to the blog! / comments
We are currently supporting TFS 2008. (There is minimal support for TFS 2005, but this hasn't been tested completely since most users seem to be on 2008.) So, SQL Source Control is looking for ei...
Hello Jim,
Any information you could provide would be extremely valuable especially the SQL Compare script showing the differences between the databases.
Would it also be possible to send the scripts for the actual objects that are different if there are not too many? It would be helpful if you could include the db version and the source control version. Or would sending snapshots of your database and the source control version be possible? (You can create snapshots using SQL Compare, select DB as source and Snapshot as target, then create a new snapshot. Link a new empty db to the same source control and get latest. Then snapshot this db as the source control version.)
Please send this information to SqlSourceControlSupport@red-gate.com. If you zip up the information, please rename the zip as .zip.txt so that it passes our security check.
Thank you!
Stephanie Herr :-) / comments
Hello Jim,
Any information you could provide would be extremely valuable especially the SQL Compare script showing the differences between the databases.
Would it also be possible to send the scrip...