I appreciate it if anyone tries to help!
We have a shared internal dev environment and one dev was working on a feature branch with updated episerver nugets and when they ran their project locally and connected to the shared episerver database, it updated the database version from 7059 to 7060 (unfortunately the setting to automatically do these updates was turned on). Now we cannot run the project on that database version without updating the nugets sufficiently. An update to episerver is not going to be deployed soon to this project so we're left with trying to figure out how to solve this mess.
Let's assume we don't have a recent backup of the database. Is there any way to 'downgrade' the episerver database from version 7060 to 7059?
Not sure if this will work but try reverting your nuget packages and manually updating the version in Database, have a look at
stored procedure to see what table it is
I'm afraid, to the best of my knowledge, there's no downgrade option so your best bet would be to roll back the database (if possible). You mentioned there's no recent backups but, depending on how your database is configured, you may still be able to roll back to a point in time. Rolling back an azure SQL database to a point in time should be pretty straightforward if you're using that. If you're using SQL server, it's not quite as straightforward but should still be possible (depending on your database recovery model). As I recall, the process involves a tail-log backup (which contains the transactions since the last backup), allowing the transactions to be replayed up to a point just before the database version was updated. I can't remember the exact process but I'm sure Google would be able to help.
I'd strongly advise against the suggestion of manually changing the database version in `sp_DatabaseVersion`. That may remove the initialisation error but basically all you're doing is masking the cause of that error. The database schema will still not match the codebase and so you'll most likely end up with many more, much harder to find errors cropping up throughout your solution. It may also cause you problems when you subsequently try to upgrade as the schema won't match the expected schema from in the database upgrade scripts.
Have a look at the very last section of my blog post, a couple of tips.https://www.gulla.net/no/blog/optimizely-content-cloud-cms-and-updates-to-the-database-schema/
Thank you for the helpful comments. I will have a look at using SQL Server transaction logs to bring an older backup up to speed, and at the very least configure a maintenance plan for frequent backups for the SQL server. It'd also probably be a good idea to have automatic database updates off for Episerver in the shared developer environment, like Tomas points out at the end of his blog.