Skip to content
← SQL Source Control

How can we improve SQL Source Control?

SQL Source Control

Categories

JUMP TO ANOTHER FORUM

(thinking…)

SQL Source Control / Red Gate Configuration Database

I think it would be nice if SQL Source Control (or Red Gate in general, in case it is useful across other products) had its own config database. This would be the one location to store all information related to this product, instead of storing some information in a database (v3.1 RG_AllObjects table), some in .xml config files, and some as extended properties on the database.

I would much rather create one database (that I could specify on install, instead of having to go into a config file and change it from TempDB) that I could host of a single instance of SQL Server and point SQL Source Control at it from any instance and any workstation I am using the product on.

I would hope this would also include a gui to make any changes, as it is more difficult than necessary right now to change things like polling interval and the logging database location. This should all be via a gui instead of having to manually go into config files. And it should all be able to be referenced from multiple machines, instead of having to configure these things on every coworkers workstation.

15 votes
Vote

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
You have left! (?) (thinking…)
Sam shared this idea  ·   ·  Report…  ·  Admin →
How important is this to you?

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
Submitting...
An error occurred while saving the comment
  • John Q Martin (@SQLServerMonkey) commented  ·   ·  Report

    After reading in the documentation that I need to manually create the database and then alter the configuration file, I have to ask why this is not dealt with when the shared database is linked to source control. The ability to track who is making changes is a fundamental requirement in this model so the use of TempDB has to be seen as inappropriate.

    I would suggest that also rather than having a single control database on the instance/server that perhaps it would be a better model to have a configuration database per-database that is linked to using the shared model. That way it is clear what it is for and that it is operating in shared mode.

    Many thanks

    JQ

  • Rachel Ambler commented  ·   ·  Report

    Totally agree. The product as it stands right now is very useful, but making it a true Client\Server model with be even better.