Settings and activity
9 results found
-
15 votes
Serge
supported this idea
·
-
13 votesSerge
supported this idea
·
-
18 votesSerge
supported this idea
·
-
3 votes
An error occurred while saving the comment An error occurred while saving the comment Serge
commented
It would be ideal to omit objects from SSC altogether, the traffic generated by schemas, security, Synonyms, Storage, etc is too great when all you may want to store in SSC is procedures, functions, and views...
-
3 votesSerge
supported this idea
·
An error occurred while saving the comment Serge
commented
We are using SVN, but it would be nice to have it auto-populate so developers see it when they go to check something in...
I'm really surprised that there's no "admin/conf" section that goes along with this software. In the case of adding a DB to source control: what if I only want to add stored-procedures, functions, and views? Currently there is no option for this, SSC add everything under the sun to the SVN repo - and when that goes over a WAN to the SVN repo, it takes time...
Serge
shared this idea
·
-
8 votesSerge
supported this idea
·
Serge
shared this idea
·
-
476 votes
Thank you everyone for the suggestions and votes for this over the years.
I’d like to surface up a workaround for the “linking” problem which is mentioned in the comments. For the use case of easing pains around environment setup with a large number of databases, we have had customers find success using code based off Alessandro Alpi’s blog post: https://alessandroalpi.blog/2016/06/28/automatically-link-databases-to-red-gate-sql-source-control/
I do understand that this is a broader issue and hear that many of you also want command line or API support for the product in general.
If there are specific scenarios or workflows that would be useful to automate for you, this feedback is also very useful, and if you have details on the type of VCS you use and the workflow (such as a branching model) that it would fit in to, that would be very helpful for us to hear as well.
An error occurred while saving the comment Serge
commented
3rd attempting to post this comment...
I've tried the steps below and the users get the linked databases, however they get a "grey" dot on them. When clicking on it they aren't prompted to get a local copy and say "yes", rather they receive an application error:There is no working folder mapping for C:\Documents and Settings\sahar\Local Settings\Application Data\Red Gate\SQL Source Control 3\WorkingBases\y40aughq.j5u.
Which they continue to get each time they click elsewhere in SSMS
An error occurred while saving the comment Serge
commented
I tried this route and it appeared to work but the users got a "grey" dot on the green linked database. There was no prompt for them to say "yes" to, rather it generated a SQL Source Control application error:
"There is no working folder mapping for C:\Documents and Settings\<user>\Local Settings\Application Data\Red Gate\SQL Source Control 3\WorkingBases\y40aughq.j5u."
(which they continue to receive while working in SSMS)An error occurred while saving the comment Serge
commented
The admin's last post was in April of 2012...It took me hours to set up and link all of the databases from 20 servers to SSC - I can't have 9 other developers doing the same thing. Surely there has to be a solid way of automatically having these developers linked to source control??? Not only do you need to give them the XML file, but you need to create one for each developer...to ensure they have the proper root path Ex: C:\Documents and Settings\doej\Local Settings\Application Data\Red Gate\SQL Source Control 3\Transients\xxx.ddz
I'm on the latest Beta...and from what I can tell there's no GUI options for SSC - does any one know if it's been added?
-
7 votes
For any objects that are CREATE OR REPLACE, highlight the code under “Source Control” in the check-in screen and execute it in your schema to get back to the version in source control.
This will not work for tables and please keep voting/commenting here if you need this.
Serge
supported this idea
·
-
79 votes
Kendra
responded
An update for users on the status of this suggestion:
An ‘object locking’ feature was added to SQL Source Control following the creation of this item which can helps users working in a shared database environment not write over each other’s changes.
This may help prevent accidental commits in some cases, as there is a “Locking” tab which allows users to see which other users are working on specific items.
Locked items are still eligible to be committed, however, and there are cases where users will want to commit an item — perhaps to a specific branch in source control which is not ready to deploy — even if the item in the database is locked.
We have found at Redgate that the easiest way to enable alignment with distributed source control systems such as Git is to empower users to use dedicated development databases rather than shared databases. Tools…
Serge
supported this idea
·
@David - that's just a filter for what you see. It still include EVERYTHING UNDER THE SUN when linking a database to Source Control. ON a slow connection across a WAN, it would be ideal to say "I only want to control: views, procedures, and functions"
It's an awful lot of over head to have to store users, tables, roles, etc. - we should have the option to control what even gets into the SSC/SVN back-end