Comments
Sort by recent activity
Right-click on table, "Link or Unlink static data": https://documentation.red-gate.com/soc/common-tasks/link-static-data / comments
Right-click on table, "Link or Unlink static data":https://documentation.red-gate.com/soc/common-tasks/link-static-data
That would probably work fine. Using the shared model is probably the quickest way to making some short-term progress. However, in my experience, the longer you use the shared model the more likely you are to reinforce monolithic/big-ball-of-mud databases that act as a single point of failure for a zillion dependent services. In the long-term this will lead to bigger challenges and nastier failures. I'm not saying that you should move to dedicated databases immediately. Maybe shared model is a good first step. However, in response to a few of your challenges I can offer the following suggestions. 3rd-party frontend apps in an ideal world, each app should manage it's own data. That's obviously a big change that won't happen overnight. Perhaps you'll never truly separate everything, but you can decide to stop exacerbating issues by avoiding this architecture for new stuff wherever possible and by looking for some of the services or groups of services that could be separated relatively easily. Circular dependencies The cloning tools I mentioned above are actually amazing at solving a bunch of these issues. They allow you to deploy one or more databases, even if they're missing dependencies, in a couple of seconds. This is a great enabler for the disposable dedicated environment workflow, either for dev or test purposes. Of course, this doesn't solve all your challenges, but it's a big help. :-) / comments
That would probably work fine. Using the shared model is probably the quickest way to making some short-term progress. However, in my experience, the longer you use the shared model the more likely...
It sounds like you understand the issues so I won't bore you with that. Obviously branching and shared databases is just complicated/broken. Assuming you use a trunk-based dev approach, it *should* work fine. Although Redgate will obviously say it isn't officially supported so don't blame them etc... Which is fair. I recommend you read (and understand) this before going ahead with it: https://documentation.red-gate.com/soc5/reference-information/how-sql-source-control-works-behind-the-scenes You'll often get into a funky state where all developers are commiting to their local git repos, so they'll likely be seeimg everyone's changes in the commit tab. There is likely to be lots of duplications and merge stuff but that *should* for the most part sort itself out. You'll be asking git to do a lot of unneccessary merging, which should be fine, but git has a reputation for being awkward sometimes. There will probs be a lot of "No-Ops" (see link above) but they *should* cancel each other out. So yeah... It *should* work. Lot's of people do do this. It's ugly, but it sorta works. Your mileage may vary. Be prepared to fix stuff when it doesn't work. What I'd like to understand more is why. I hear the desire to link commits to work items and stories, but wouldn't it make more sense to achieve that through branching and pull requests using dedicated databases? If you did it that way git would be actively helping you, rather than just complicating things. You'd be able to get the best out of both TFS, Git and Redgate. If you are concerned about data and the storage, admin or data privacy challenges associated with managing many dedicated databases, you should check out Redgate SQL Provision. It's ace. https://www.red-gate.com/products/dba/sql-provision/ / comments
It sounds like you understand the issues so I won't bore you with that. Obviously branching and shared databases is just complicated/broken.Assuming you use a trunk-based dev approach, it *should* ...
Hard agree. For TFS, check out this link instead: https://github.com/MatthewFlatt/SOCAutoLinkDatabases (The link I shared originally was updated to support Git. However, it was based on this earleir version which was designed to be used with TFS.) That said *everything* is much easier once you move to Git. ;-p / comments
Hard agree.For TFS, check out this link instead:https://github.com/MatthewFlatt/SOCAutoLinkDatabases(The link I shared originally was updated to support Git. However, it was based on this earleir v...
I also wish this feature was built in. Unfortunately, it isn't. Fortunately, you can script it: https://github.com/EngageITServices/SOCAutoLinkDatabasesWorkingFolder / comments
I also wish this feature was built in. Unfortunately, it isn't. Fortunately, you can script it:https://github.com/EngageITServices/SOCAutoLinkDatabasesWorkingFolder
Ha ha! Still, I like the philosophy of every time you hit a bug/error, write a test to avoid it repeating. 😝 / comments
Ha ha!Still, I like the philosophy of every time you hit a bug/error, write a test to avoid it repeating. 😝
Might be worth thinking about using tSQLt to create some basic unit tests. Or, if accidental drops are a regular issue for you, you could automated a test on your build server to throw a warning whenever an object is dropped. There are a few ways to achieve that. / comments
Might be worth thinking about using tSQLt to create some basic unit tests.Or, if accidental drops are a regular issue for you, you could automated a test on your build server to throw a warning whe...
What underlying source control system are you using with Redgate? Git? TFVC? SVN? Might be easier to use the underlying source control tool. / comments
What underlying source control system are you using with Redgate? Git? TFVC? SVN?Might be easier to use the underlying source control tool.
This is not possible with SQL Compare. However, what is possible is to ignore the table in SQL Source Control/SQL Change Automation and use post-deploy scripts to manage this column. If you do this, source control would be "the truth" and any changes made in production would be ignored. Without understanding your use case in a bit more detail it's hard to know whether this would be an acceptable solution for you. / comments
This is not possible with SQL Compare.However, what is possible is to ignore the table in SQL Source Control/SQL Change Automation and use post-deploy scripts to manage this column.If you do this, ...
That's correct. You would need to ensure everyone understands that changes to triggers on filtered out tables need to use the post deploy script instead. If you extract the trigger creation into a sproc, and then call the sproc from the poat-deploy, changes will be spotted by SoC, but you would still need to remember to update the poat-deploy. Alternatively, you could have a DEPLOY_ALL_TRIGGERS sproc that loops through all the DEPLOY_TRIGGER_1, DEPLOY_TRIGGER_2, etc scripts based on some naming convention. That way all you need to put in your poat-deploy is: EXEC DEPLOY_ALL_TRIGGERS And you shouldn't ever need to update it again. Of course, folks will still need to remember that the triggers are handled with the associated sprocs. An alternative approach would be to add some tests to your build/deploy pipelines to ensure that all the appropriately named deploy_trigger sprocs are referenced by the coordinating script and vice versa. / comments
That's correct.You would need to ensure everyone understands that changes to triggers on filtered out tables need to use the post deploy script instead.If you extract the trigger creation into a sp...