My database version (7048) is ahead of what my code expects (7047

My database version (7048) is ahead of what my code expects (7047)

Vote:

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.

updateDatabaseSchema is already set to 'true," but remember that we're not "updating," as much as we need to go back one version.
I ran "Update-EPiDatabase" from the Package Manager Console. It ran through a whole bunch of SQL files very, very quickly. I checked them out -- I doubt any of them did anything, because they all check the database version, and the most recent one (10.9.0) abandons if the database is greater than 7047, which it is.

So...what do I do now? How do you "downgrade" a database?

#186306

Edited, Dec 16, 2017 0:47

Vote:

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.

#186307

Dec 16, 2017 1:01

Vote:

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?

#186311

Dec 16, 2017 16:09

Vote:

>"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.

#186372

Edited, Dec 18, 2017 18:15

Mark Everard

Vote:

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.

#186382

Dec 19, 2017 0:23

Vote:

This, this is what happened. Someone upgraded a shared database on a different branch. Not ideal, but we merged and got past it.

#186457

Dec 19, 2017 21:10