Comments
Sort by recent activity
It's not available out of the box - but it could probably be automated using some sort of DDL triger and the SQL Compare command line. That said, any automated solution like that fills me with dread. It feels particularly painful to support/maintain. Much easier to get into the habbit of saving changes in SQL Source Control (using the "working folder" option) and then using the prefered git tool to manage commits/pushes etc. / comments
It's not available out of the box - but it could probably be automated using some sort of DDL triger and the SQL Compare command line.That said, any automated solution like that fills me with dread...
Yes / comments
Yes
1. Have you looked at using a SQL Change Automation project instead of a SQL Source Control project. It's migration script based, rather than disired state-based like SQL Source Control. It basically works exactly like that: https://documentation.red-gate.com/sca/developing-databases 2. If you want to stick with SQL Source Control, you can set up an automated build task using the SQL Change Automation PowerShell cmd-lets: https://documentation.red-gate.com/sca/reference/powershell-cmdlets For example, if you created a new DatabaseReleaseArtifact for each commit, using the latest source control version as the source and the prod DB (or a copy of the prod DB) as the target, you could publish this release artifacts to a shared location. That release artifact will contain: - Copy of source schema - Copy of Target schema- Update script - Human readable diff report with any warnings etc
/ comments
1. Have you looked at using a SQL Change Automation project instead of a SQL Source Control project. It's migration script based, rather than disired state-based like SQL Source Control. It basical...
After running git clean, did your issues persist? (I'm assuming so). At this point I think I'm out of suggestions. I suspect it's one for Redgate tech support. Good luck! / comments
After running git clean, did your issues persist? (I'm assuming so).At this point I think I'm out of suggestions. I suspect it's one for Redgate tech support. Good luck!
It should do. Most of my clients use Git repos that contain multiple DBs. Have you tried opening a command prompt to the DB directory and running a git status and a git clean? Does that give you any more feedback or provide any unexpected surprises? / comments
It should do. Most of my clients use Git repos that contain multiple DBs.Have you tried opening a command prompt to the DB directory and running a git status and a git clean?Does that give you any ...
So the entire DB is showing as a change... What sort of change? New objects? Modified objects? Deleted objects? I'm assuming you were expecting them to be in sync? / comments
So the entire DB is showing as a change... What sort of change? New objects? Modified objects? Deleted objects?I'm assuming you were expecting them to be in sync?
Is there a redgate.ssc file at the exact path you committed to? Does the code in the repo match the code in the DB? / comments
Is there a redgate.ssc file at the exact path you committed to?Does the code in the repo match the code in the DB?
Have you tried deleting the local repo and pulling down a fresh clone? (Obviously commit and push or otherwise save any local updates/commits before deleting the local repo to avoid losing work.) / comments
Have you tried deleting the local repo and pulling down a fresh clone?(Obviously commit and push or otherwise save any local updates/commits before deleting the local repo to avoid losing work.)
Do you by any chance have any of the files open/selected/locked in any other programs? (E.g. file explorer/text editor). Do you have full access to the filesystem where your git repo is located? / comments
Do you by any chance have any of the files open/selected/locked in any other programs? (E.g. file explorer/text editor).Do you have full access to the filesystem where your git repo is located?
Are you using a SQL Source Control projects or a SQL Change Automation Project? In either case, I'd create a post-deploy script with logic along the lines of: IF (Env is Dev) { Set up these dev users } IF (Env is prod) { Set up these prod users } Alternatively, for simplicity you may prefer to extract your dev/prod user security scripts into separate scripts/sprocs that are siimply referenced from your post-deploy script. In this way your security is version controlled in an environment specific manner. If using SQL Change Automation you could deternmine the environment using a SQL environment variable. If SQL Source Control you will probably either need to hardcode server name (I know, yuk) or use a config table in the DB with data specifying whether the database should be set up in the dev and/or prod security configuration (make sure security on this table is locked down in prod to ensure appropriater access controls are maintained). / comments
Are you using a SQL Source Control projects or a SQL Change Automation Project?In either case, I'd create a post-deploy script with logic along the lines of:IF (Env is Dev) { Set up these dev us...