Settings and activity
14 results found
-
29 votes
An error occurred while saving the comment -
15 votes
An error occurred while saving the comment 
James Billings
commented
Thanks for the suggestion- have you tried the view history screen? That should show who made each commit against your VCS which might be helpful: http://documentation.red-gate.com/display/SOC3/Viewing+source+control+history
Obviously if seeing this on the Get Latest tab proves a popular suggestion, then we'll consider it.
-
1 vote
An error occurred while saving the comment James Billings
commented
If Get Latest fails while applying the changes to your database, you should see a link to "manually edit the script" on the error. This will open up the script in SSMS so you can try executing it and see/fix any errors.
-
70 votes
An error occurred while saving the comment James Billings
commented
It sounds like you're using what we'd term "hybrid" model- where you have several databases with multiple users working on them that are all part of the same project. Unfortunately this leads to the problem you're experiencing as the "Get Latest" tab doesn't do anything when you're working shared model.
Another option is for one user to temporarily unlink, relink in dedicated, do a Get Latest to update the database (which will update it for all other users working on the same DB) and then relink back in shared model again.
In the longer term we're looking at improving this, which may well include removing the shared/dedicated choice altogether (it's really a choice that users shouldn't have to worry about and is there more to help the product)
-
6 votes
An error occurred while saving the comment James Billings
commented
Hi,
Whilst I'm not sure this is something we'd look at any time soon, I wonder if you could clarify the exact requirement (out of curiosity!)- the login to the SQL Server is handled via SSMS, so I'm guessing you mean a login to your VCS? In some cases (such as Visual Studio Online) we merely show the standard login dialog, so couldn't do much about it, but for others, such as SVN, we pop up our own username/password box and could potentially make changes. The vast majority of VCS clients will then cache your login credentials though, so you only have to log in once anyway. -
8 votes
An error occurred while saving the comment James Billings
commented
The filter works *after* the comparison process across the whole database has finished. While I can see how this seems wrong at first glance, we need to do it this way to correctly work out all the dependencies in the database. It may well be that some of the objects that are filtered out are relied on by objects you want to change, and we need to be able to warn you of this, and it's required by our engine to understand the structure of the whole DB to function correctly - the same as SQL Compare.
If there's no dependency link between the vendor objects and the customer ones, could you split out the DB to just contain the objects you're frequently working on? That may help.
-
1 vote
An error occurred while saving the comment James Billings
commented
You should already be able to do this- above the list of objects to commit, there will be a checkbox in the header row as well. Selecting that should select all the objects.
If you meant something different, then please do clarify though! -
2 votes
An error occurred while saving the comment James Billings
commented
Normally, if our engine has to disable triggers during an update, it should re-enable them afterwards again. The Undo option will basically update your DB to the copy from the repository- if the object you're updating has a trigger on it in the repo, that should survive intact after the undo process. If, we're disabling triggers on related objects to the one you're undo-ing, and not re-enabling them afterwards, that sounds more like a bug, and a specific example would be useful.
-
9 votes
An error occurred while saving the comment James Billings
commented
SQL Compare has an option to Ignore users' permissions and role memberships which, according to the tooltip does this:
"When role-based security is used, object permissions are assigned to roles, not users. If this option is selected, SQL Compare compares and deploys object permissions only for roles, and members of roles that are roles. Users' permissions and role memberships are ignored".Does that option help at all? If it does, you can set it in SQL Source Control as described here: http://documentation.red-gate.com/display/SOC3/Setting+SQL+Compare+options+in+SQL+Source+Control
-
3 votes
An error occurred while saving the comment James Billings
commented
Thanks for your post. This board is really aimed at feature suggestions rather than getting support for technical issues. Could you please supply some more details of what you're seeing, and ideally enclose a recent logfile from when the problem occurred (you'll find these in c:\users\<your username>\appdata\local\red gate\logs\sql source control 3) over to support@red-gate.com? If you can also let us know the size of your database, how many users you have, what source control system you are using, and anything else that may be relevant, it'll all be helpful. Thanks!
-
1 vote
An error occurred while saving the comment James Billings
commented
Most likely you're seeing activity from SQL Source Control polling for changes to the database. You can reduce the frequency of this by editing a configuration file:
Edit the RedGate_SQLSourceControl_Engine_EngineOptions.xml file in C:\Users\<username>\Appdata\Local\Red Gate\SQL Source Control 3.
Set the trace interval time as follows:
<DefaultTraceMinimumInterQueryTimeInMillis>60000</DefaultTraceMinimumInterQueryTimeInMillis>
(you may need to add that line if it's not already there).
Once done, ensure you restart SSMS; also, you will need to perform this change on each PC / for each user.
-
34 votes
An error occurred while saving the comment James Billings
commented
We wouldn't normally suggest linking a production database to SQL Source Control. If you need to update the development database with changes from production, you'd ideally look at deploying the changes over using SQL Compare, and then committing the update into SVN from SQL Source Control in the usual way.
-
35 votes
For now, enter your BugID into the comment field when you commit changes.
Please continue to vote/comment here if you would like to see a seperate Bug ID box like TSVN has. See James’ comment for more details.
An error occurred while saving the comment James Billings
commented
Benny, not sure where Simon's comments went, but we've found it internally, so I've added it below - you might also want to read over the way you can use them in the commit box, here: http://bit.ly/kyr6aZ
The BugID in SVN is not actually a checkin property. Bug IDs are recognized by the SVN property bugtraq:logregex. This means that if your SVN is configured for bug integration with other tools then typing the bug IDs into the commit box in SQL Source Control should work.
In the Tortoise UI configuring these properties enables the Bug ID box. filling the box in post fixes the bug ID onto your commit message (something like "This commit fixes issue <WhatYouTyped>". Whilst we do consider it useful to have a similar bug id box, you should be able to integrate already! -
38 votesJames Billings
shared this idea
·
What Tim was suggesting is using Get Latest instead of the restore, which would update your dev databases to whatever is currently in the source control repository.
Are you restoring from a backup because that's more recent than what's in the repository?
The reason that you see the objects on the commit tab is because the restore has made changes to the database which haven't also been made to the "working base" scripts folder. We see differences in these as changes you need to commit (see http://documentation.red-gate.com/display/SOC3/How+SQL+Source+Control+works+behind+the+scenes for more information on this). Doing a Get Latest from the repo will update the WB and Database together, so you won't see spurious differences on the commit tab.