I have the problem of a database version ahead of my code, which is weirdly backward. Usually, you have a database version lagging behind your code, that needs to be upgraded, but I have this:
The database schema for 'CMS' has not been updated to version '7047.0', current database version is '7048.0'. Update the database manually by running the cmdlet 'Update-EPiDatabase' in the package manager console or set updateDatabaseSchema="true" on episerver.framework configuration element.
I restored a database from my client and cloned their repo. This is what I get. They don't have any problems. No idea why I have an issue, but this is strange.
So...what do I do now? How do you "downgrade" a database?
So, I "hacked" this by just manually changing the sp_DatabaseVerson stored proc to return "7047" instead of "7048" (it's just a hard-coded return statement). I realize this isn't ideal, but this is a development version of a database I will never deploy.
Still weird. If anyone has any ideas, let me know.
Sounds like there has been some mix of nuget package versions somewhere?
If your solution is using several csproj, one of the csprojs might use another version than the version that ends up in your bin folder? Check the "Consolidate" tab in the NuGet Package tool (open the tool for the solution, not a specific csproj).
Is it a shared database? Could some of your colleagues have tested an upgrade but never pushed the code?
>"Could some of your colleagues have tested an upgrade but never pushed the code?"
I think that was probably it. The hack I mentioned above has been enough to get me moving again.
We've had this when using gitflow / feature branching where one of our features is a CMS upgrade. We can't individually deploy the feature branch to a QA environment without effectively locking that environment to that feature branch.
Editing the Stored proc is the only way I've found around it, well that and making sure when we do upgrade we prioritise only that feature and push it to release quickly. Easy enough for a weekly release, but not quite as easy for a major version release. Still we're only talking days of effort for those nowadays rather than the weeks of effort I remember!
TLDR; Major version upgrades should still be treated differently than a standard release.
This, this is what happened. Someone upgraded a shared database on a different branch. Not ideal, but we merged and got past it.