User profile for StephanieHerr

A fix will be available early next week. This is the week beginning April 19th. I hope this is ok. / comments

A fix will be available early next week. This is the week beginning April 19th. I hope this is ok.

0 votes

Thank you for reporting this issue. We are working on a fix for this. We should have another release next week. I hope you can wait until then... / comments

Thank you for reporting this issue. We are working on a fix for this. We should have another release next week. I hope you can wait until then...

0 votes

Thank you for letting us know about this issue. Our internal reference number is SOC-900 and we are currently looking into this. / comments

Thank you for letting us know about this issue. Our internal reference number is SOC-900 and we are currently looking into this.

0 votes

Hi, We are currently working on this issue. It's surprising how many people have # in their db object names... :-) Would you be able to email us a copy of the dbo.USPEmp# to SqlSourceControlSupport@red-gate.com? This way, we could recreate the exact issue that you are having and test it internally. This will only be used for our internal test purposes. Our internal reference number is SOC-599. Thanks for your help! Stephanie M. Herr :-) SQL Source Control - Project Manager / comments

Hi, We are currently working on this issue. It's surprising how many people have # in their db object names... :-) Would you be able to email us a copy of the dbo.USPEmp# to SqlSourceControlSuppo...

0 votes

We have been able to reproduce the GO alias problem here. Would it be possible to use a different alias for now? / comments

We have been able to reproduce the GO alias problem here. Would it be possible to use a different alias for now?

0 votes

1) You must have Team Explorer installed on your client machine that is using SQL Source Control through SQL Server Management Studio (SSMS). You will probably want to install Team Explorer 2008. (If Team Explorer is NOT installed, then you will see a missing prerequisite message when you select the TFS radio button when linking your db to source control.) 2) You should create an emtpy "Database" folder in your TFS repo. To do this: - Open Visual Studio - Select View > Team Explorer - Add an existing Team Project - Connect to a Team Foundation Server - Double click on the "Source Control" folder, this will open the "Source Control Explorer" - Right click on the tree and select Get Latest Version - Navigate to where you want to create your database folder - Right click in the main explorer window, not the tree - Select New Folder - Give your new folder a name - Right click on the folder and select "Check In Pending Changes..." - Add a comment and click Check In 3) Now back in SSMS, right click on a db and select "Link DB to source control...." 4) On the setup tab, click the "Create new link to source control..." link 5) Select TFS if this is not the default. (SQL Source Control will remember the last source control system you linked to.) 6) Select or enter the TFS Server URL. 7) If you have Team Explorer 2008 installed, then you can Browse the Team Foundation Server and select the empty folder you created. 8) Click "Create link" 9) Click on the "Commit changes" tab. Enter a comment like "initial db baseline" or "initial commit" and click "Commit." Your db is now linked to source control and your initial commit is completed. Now you can have other users link their db to the same central repo. You're ready to start making changes to your dev db and once you're happy with the change, right-click on the db or node under the db and select commit changes. This brings you back to the commit changes tab. Enter a comment and commit your changes. I hope this helps! / comments

1) You must have Team Explorer installed on your client machine that is using SQL Source Control through SQL Server Management Studio (SSMS). You will probably want to install Team Explorer 2008. ...

0 votes

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...

0 votes

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 ...

0 votes

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...

0 votes

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...

0 votes

How can we help you today?

StephanieHerr

Comments