Comments
Sort by recent activity
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...
There are a couple of things you could do to get around this issue. Neither are perfect, but they should work. 1. Move to a migrations based approach. If your developers use a SQL Change Automation project, rather than a SQL Source Control project, the deployments will be based on scripts that were curated by the developers so you would avoid unexpected column drops. 2. Move to a master == production branching strategy, and set up a process to detect and automatically add changes made in production directly to master. If this ever fails, you will get a broken build to alert you to an issue. All development changes would need to be done on a branch and merged with master when they are ready to be deployed. Obviously these are both avoiding the issue rather than fixing it. In an ideal world the 3rd party product updates would be going through source control too. / comments
There are a couple of things you could do to get around this issue. Neither are perfect, but they should work.1. Move to a migrations based approach. If your developers use a SQL Change Automation ...
How about this? Master = Production. Dev work is done on feature branches on development databases. (Ideally separate databases per feature/developer. Have you looked at SQL Provision?) On demand, plus on a periodic basis (e.g. at the weekend/at end of sprint) the following is automated: From your post above: 1) restore latest prod on the dev server as <DB>_FROM_PROD_<yyyMMdd_hhmmss> 2) rename the dev <DB> to <DB>_OLD 3) rename the <DB>_FROM_PROD_<yyyMMdd_hhmmss> db as <DB> My additions: 4) <DB> is compared with master in source control, any updates are automatically committed as "DRIFT CORRECTION". This should get all 3rd party and other updates on prod into master. When this occurs you may want to trigger some sort of notification to your team so they can review the updates. 5) master is automatically merged with all branches. If this merges nicely, wonderful, your development changes do not conflict with production drift. If this causes a merge conflict/build error, your developers need to review the problem before they can push to production. To release code to production: 1) Automatic check that production and master are in sync. If not, abort with a drift warning. Resolve drift by updating master and try again. 2) Master is merged into feature branch to ensure there are no merge conflicts. 3) Any automated tests are run to verify the merged code. (If you don't have tests, write some.) 4) Feature branch is merged into master. 5) Master is deployed to production. 6) Master is merged into any other feature branches. / comments
How about this?Master = Production.Dev work is done on feature branches on development databases. (Ideally separate databases per feature/developer. Have you looked at SQL Provision?)On demand, plu...
There isn't a rollback migration feature. If it was me, I'd kill and respawn my database each time I switched branches. If you care about data, SQL Clone is your answer. / comments
There isn't a rollback migration feature.If it was me, I'd kill and respawn my database each time I switched branches.If you care about data, SQL Clone is your answer.
It doesn't. This is both a good thing and a bad thing. For example, SSDT gives you great build output based on your cross-DB dependencies, but they also become almost impossible to manage. With the Redgate approach it is far easier to decouple your source control projects and work on them in manageable chunks. Then you can pickup on broken database dependencies by running your builds on an integration server instance. This still gives you the fast feedback, but enables far simpler database development. However, it comes with the cost of maintaining a persistent integration environment. Obviously, the ideal solution, is to work towards a more loosely coupled architectiure, avoiding direct dependencies between databases where possible. / comments
It doesn't.This is both a good thing and a bad thing. For example, SSDT gives you great build output based on your cross-DB dependencies, but they also become almost impossible to manage.With the R...
I suspect you only have a licence for SQL Compare Standard. Comparing against source control / scripts folders is a SQL Compare Pro feature. [image] https://www.red-gate.com/products/sql-development/sql-compare/ / comments
I suspect you only have a licence for SQL Compare Standard. Comparing against source control / scripts folders is a SQL Compare Pro feature.https://www.red-gate.com/products/sql-development/sql-com...