How to set git to work as a Shared Database?

pablolernerpablolerner Posts: 27 Bronze 1
in SQL Source Control
I am trying to use config files to set git to work with a Shared Database. My intention is to bypass the stage/index thing and force git push after every commit. And then force git pull before every time Source Control compares the database with the git repository. But I don't really understand how to set all of this up. Is there any documentation on how to achieve this?
Tagged:
· Share on Twitter

Best Answers

  • ATurnerATurner Posts: 204 Silver 2
    edited June 7, 2021 3:40PM Answer ✓
    Hi pablolerner

    Our native Git connection does not allow shared DBs.

    This is by design as we believe that git should be used with dedicated databases only 


    · Share on Twitter
  • DanCDanC Posts: 639 Gold 5
    Answer ✓
    pablolerner said:
    ATurner said:
    [...]you would have to commit with your preferred source control tool separately[...]
    Hello. I don't know how much others will agree but this is not something that I, as a database developer and user of SQL Source Control, can call "suppor for Git". What you are describing is just support for script files in the file system and then using Git as a completley sepparate tool. What I need, and please I ask the other users in this thread to clarify if they do too, is for SQL Source Control to provide all the functionality within it self, without using external tools.
    By the way, going back to my original question in this thread, I was never able to make this work for me.
    Hi,

    If you're using a Dedicated Database then you will have full support for Git within SQL Source Control, however, if you're working on a Shared Database you cannot link directly to SQL Source Control with Git as this is a limitation due to our native Git connection does not allow for shared dbs. 

    Therefore, you will need to use the option of linking to a Working Folder or use a custom setup: https://documentation.red-gate.com/soc5/linking-to-source-control/other-source-control-systems/link-to-a-custom-setup

    You can then use the command line to perform your commits, push and pulls.

    This behavior is unlikely to ever change due to the technical limitations, sorry that's not ideal

    Kind regards

    Dan Calver | Redgate Software
    Have you visited our     Help Center?

    · Share on Twitter

Answers

  • pablolernerpablolerner Posts: 27 Bronze 1
    Thanks for the answer.
    · Share on Twitter
  • DavePaulDavePaul Posts: 3 New member
    ATurner said:
    Hi pablolerner

    Our native Git connection does not allow shared DBs.

    This is by design as we believe that git should be used with dedicated databases only 


    Hello ATurner,

    thank you very much for the information.
    My company relies completely on GIT for source code management.
    Unfortunately, we have some fullstack developers who do not have a license for Redgate SQL Source Control and also some other employees to whom this applies.
    Also, we have a high number of large databases (about 50 databases with up to 750 GB each).
    Therefore only the "Shared database" mode is practicable for us.

    Is there a way to implement this mode with GIT in the meantime?
    Or is this feature planned for the future?

    If there are no technical restrictions, why does Redgate simply decide that only the "Dedicated databse" mode can be used with GIT?

    Kind Regards
    Dave
    · Share on Twitter
  • LeeRobinsonLeeRobinson Posts: 19 Bronze 2
    I have similar questions about SQL Source Control.  Dedicated databases are not practical for us.  SQL Clone costs nearly $10,000.  I am tempted to go find something like ApexSQL Source Control that does support shared database mode.

    I did find a way to link with shared mode but the documentation only shows half of what is it needed to do it.  Essentially, all that SQL Source Control does is write scripts for the database objects into text files and then says "OK, use your own tools from here on out."  The Git GUI that comes with Git works fine, but, if it is so simple, why is Red Gate ignoring it?
    · Share on Twitter
  • ATurnerATurner Posts: 204 Silver 2
    Hi LeeRobinson

    We do support a shared model within SQL source control with source control but as you mention you would have to commit with your preferred source control tool separately. This will allow you to set it up in a shared model and will then give you the ability to push to changes when you need via your source control tool. 
     
    Below is the link to our documentation on this method:
     
    https://documentation.red-gate.com/soc/linking-to-source-control/other-source-control-systems/link-to-a-working-folder 
    · Share on Twitter
  • LeeRobinsonLeeRobinson Posts: 19 Bronze 2
    Yes, saw then in my investigation.  It does not make any sense to me why Red Gate would go to the effort to make the SQL Source Control work with some local repositories and not these.  As a developer, I don't see any significant difference.  Of course, they would not sell as many copies of SQL Clone that way.
    · Share on Twitter
  • pablolernerpablolerner Posts: 27 Bronze 1
    ATurner said:
    [...]you would have to commit with your preferred source control tool separately[...]
    Hello. I don't know how much others will agree but this is not something that I, as a database developer and user of SQL Source Control, can call "suppor for Git". What you are describing is just support for script files in the file system and then using Git as a completley sepparate tool. What I need, and please I ask the other users in this thread to clarify if they do too, is for SQL Source Control to provide all the functionality within it self, without using external tools.
    By the way, going back to my original question in this thread, I was never able to make this work for me.
    · Share on Twitter
  • LeeRobinsonLeeRobinson Posts: 19 Bronze 2
    When I tried it, I ended up with a list of un-staged script files.  Even the Red Gate support people were confused about it when I submitted a support ticket.  One said that, when he does it, the files are already staged.  The other said that, when he tested it his results were the same as mine and he would consult with the developers.  Looks like they really have not gotten their act together on Git.  The article to which I have been referred several times, https://productsupport.red-gate.com/hc/en-us/articles/360007957193-Using-Shared-Mode-with-Git does not saying anything about how to use shared mode with Git.  It just described some unlikely scenario that does not occur in our environment and uses it as a justification to ignore shared mode.  I have been a developer for 40 years and writing SQL code for nearly 30 and none of the "reasons" for insisting on dedicated databases make any sense to me.  They seem to be oblivious to the fact that the databases are not programs and do not function in an isolated environment.  Setting up and using a dedicated database has an enormous overhead.
    · Share on Twitter
  • LeeRobinsonLeeRobinson Posts: 19 Bronze 2
    Just tried out an evaluation version of ApexSQL Source Control.  Shared mode with Git works very well there.  They don't appear to have any of the technical limitations that Red Gate is having. 

    Must be a different set of developers working on Red Gate SQL Source Control than on SQL Prompt.  Prompt is a wonderful product and life would be must more tedious without it.  Don't know what happened to SQL Source Control.
    · Share on Twitter
  • David AtkinsonDavid Atkinson Posts: 1,458 Rose Gold 2
    @LeeRobinson - In a different forum thread I suggested that you try Flyway Desktop, which is our next generation rewrite of SQL Source Control. Is this something you've tried? Its git support is much more aligned to native git, which may be something that works for you. I can assure you that the developers are working hard to improve the overall experience, but the task of reimplementing a product from the ground up is non-trivial, and we're trying our best to not only rebuild what we have, but also to improve the experience in the process. If Flyway Desktop still doesn't meet your needs, please give us this feedback as it would help us ensure that SQL Source Control's replacement meets customers' needs.

    David Atkinson
    Product Manager
    Redgate Software
    · Share on Twitter
  • LeeRobinsonLeeRobinson Posts: 19 Bronze 2
    Just reviewed the information about Flyway Desktop.  Our needs are so light that we might be able to make do with the Community version.  Does it require Java?  I noticed a mention of Java compatibility and Maven repositories.
    · Share on Twitter
  • David AtkinsonDavid Atkinson Posts: 1,458 Rose Gold 2
    @LeeRobinson
    Flyway Desktop doesn't currently have a community version. Flyway's command line does have a community version. It is implemented in Java, but this is packaged with the command line, so no need for you to install it separately. You also have the option to call the Docker Hub CLI.

    The paid editions of Flyway Desktop will provide a SQL Source Control-like GUI experience. ie, maintaining an object-level schema model that can be source controlled. Flyway Community only provides a mechanism to deploy "migration scripts" against a database. It doesn't have a schema model.
    David Atkinson
    Product Manager
    Redgate Software
    · Share on Twitter
  • LeeRobinsonLeeRobinson Posts: 19 Bronze 2
    When I tried it, I ended up with a list of un-staged script files.  Even the Red Gate support people were confused about it when I submitted a support ticket.  One said that, when he does it, the files are already staged.  The other said that, when he tested it his results were the same as mine and he would consult with the developers.  Looks like they really have not gotten their act together on Git.  The article to which I have been referred several times, https://productsupport.red-gate.com/hc/en-us/articles/360007957193-Using-Shared-Mode-with-Git does not saying anything about how to use shared mode with Git.  It just described some unlikely scenario that does not occur in our environment and uses it as a justification to ignore shared mode.  I have been a developer for 40 years and writing SQL code for nearly 30 and none of the "reasons" for insisting on dedicated databases make any sense to me.  They seem to be oblivious to the fact that the databases are not programs and do not function in an isolated environment.  Setting up and using a dedicated database has an enormous overhead.
    · Share on Twitter
Sign In or Register to comment.