A question about upgrading from 14 to 15

Hi.

I've been reading as much as I can on the process of upgrading but still find myself with a few questions. My memory is that when I upgraded from 12.5 to 14 I failed to make a database back-up and lost all those projects. This time I've done a back-up of my 14 datbase and have exported all my individual project files. Where I seem to be getting mixed messages is on what happens next.

Some things I've read seem to say that when 15 is uploaded it will say "would you like to up-grade your database", and that when you select this your 14 database will be upgraded and your 14 projects will now become active; that is, you don't have to import the old database as part of this process. Yet, my remembered experience with 14 is that when it was installed it didn't retain and upgrade the old 12.5 database.

And why do so many things I've read (primarily a long piece by Patrick Inhoffer) emphasize the impotance of exporting and backing up both database and project files? Is this simply as a safely measure in case something screws up when upgrading to 15? Inhoffer says:

"Are you going to upgrade active or recent projects? If so, then before upgrading you need to export those projects. And then NEVER upgrade the original project! You will only ever import that exported version of the project, always leaving the original intact and untouched.

Are you going to upgrade an existing Database, with existing projects? If so, then export that database and NEVER upgrade the original database. The key is to always leaving the original intact and untouched."

In what he says I can't get the link he's making between that exported database and the creation of the database in 15. Equally, I can't understand why and in what way an imported project file or database would not necessarily be reconfigured within 15, yet Inhoffer even places in italic his admonition to "always leave the original intact and untouched."

So here's hoping someone can help me understand all this. until I do I'm going to be too nervous to upgrade to 15.

Thanks.

John

and it fails to mention a reaalllllly IMPORTANT part... validateing the saved Database, that failure is a critical flaw... i've seen databases not restore, and not even support could save the projects inside

i think it was Dwayne or Rohit who suggested;
1- save DRP's of all active projects (should do this several times a day anyway)
2 - save database
3 - restore database
4- upgrade restored database

i typicaly do this;
1- save DRP's of all active projects - i do this several times a day currently for safety
2 - save database
3 - make new database
4- upgrade new database
5 - restore DRP's as needed

but the advice to
1- save database
2- save save DRP's of all active projects
3- upgrade database
would be workable, you are relying on the saved DRP's here so no redundancy and a single fail point, not as safe as the other options

Yet, my remembered experience with 14 is that when it was installed it didn't retain and upgrade the old 12.5 database.

I'm not on Mac, so there will be more knowledgeable folks here, but as I recall, databases on the Apple store app and the regular version of Resolve are stored in different locations. So if you switch versions, one may not be able to find the db of the other.

That aside, my approach, FWIW, at your own risk, is much simpler. I don't make Resolve system backups of the db. I just copy the db folder to another disk. If I'm really worried, I copy it to more than one location. This way, the internal "restore" process isn't needed, and can't fail (of course, there's always a chance of corruption in making the copy). You may also wish, for redundancy, to make .drps of every project, before the upgrade.

Then I just follow the prompts to upgrade the db (yes, the original). Am not sure what provoked P.I.'s cautionary harangue.

If I'm really worried, I copy it to more than one location. This way, the internal "restore" process can't fail, barring some sort of file corruption in the process of copying the folder.

Can Resolve's clone tool be used to make a checksum copy of a database to ensure the copy was completed with no errors?

Clone is for files. Don't think it will be work for dbs.

EDIT: it DOES work. See below.

Clone is for files. Don't think it will be work for dbs.

That's what I figured but thought it would be worth checking. Thanks

Hi.

Still wondering if someone has an answer to my specific question. I've attached below a link to a short video I found on Youtube that shows the steps in upgrading from 14 to 15. It includes an initial step of backing up the 14 database but later in the video, when 15 has been installed, it simply says to click on the option that appears (Would you like to upgrade the database?) and then we see the database and projects reappearing. Nowhere in this video does it suggest a step where you have to re-connect to the backed-up database.

It does show, as part of the menu that appeared saying “Would you like to upgrade the database?” a comment, in smaller type, saying “You cannot undo this action. It is recommended that you back up your existing database before proceeding”. So, if it is not to refer to and use this exported and stored database at sometime in the process of upgrading to 15, why are we recommended to make this back-up of the 14 database? Is that just in case something goes wacky in the process of the upgrade? For, as I say, in this video it seems you are upgrading the old 14 database that Resolve stores on the same hard drive as its software.

And if one need not use that exported database in the process of upgrading and creating a new database in 15, why is Inhoffer, in his comments quoted above in my initial message, so adamant about “always leaving the original intact and untouched”?

And Dermot Shane, you mention the importance of "validating the saved database". How, can I ask, does someone do that?

You make a backup of the 14 db in case you need to revert to version 14, since once you upgrade the db to 15, the project files will be unreadable in any earlier version.

And you backup the 14 db for all the other usual reasons -- if something gets corrupted in the conversion to 15, for example.

Only Patrick Inhofer can answer for the advice he's giving, with which I don't agree (provided you take the other recommended precautions). I'll let Dermot Shane answer the question you addressed to him, since it looks like you're following his advice, not mine.

If you indicate you want to upgrade the db, there's no need to manually reconnect to it. You wouldn't get the offer, if the db wasn't already connected.

Thanks very much for your reply, John Paines. Your explanation of what's happening in the upgrade to 15 seems to be what I thought it must be – the 14 database within the main drive is permanently upgraded, the exported database exists only to protect against a situation where the 15 install corrupts, or to have access to a database you can continue to use with 14.

That leads me to a couple of other questions. First, as I understand it the only way you can continue using 14 is to create a partition in the boot drive and install 15 to it - leaving 14 active in the other partition. Am I correct in saying that's the only situation where one could find oneself able to continue using 14 and the exported database? Second, would this same situation exist for backed up project drp files? I regularly back-up all these on a separate drive. Would I be able to import any of these into 15 if I had to/wanted to?

As for my question to Dermot Shane about the backing up of the 14 database, I was only curious what he meant when he talked of “validating the saved database” and also about how one would “validate” it. I must admit I'd yet to give thought to your suggestions vis a vis a database back-up. I see how it would be easy to simply copy the database from the main drive to a back-up one without going through Resolve. You say that by doing this “the internal 'restore' process isn't needed”. Can I ask you what you mean by that?

Thanks again. Your comments and explanations are much appreciated.

John

I have no experience of house-keeping on a current Mac, so can't advise on whether two versions might be installed on one boot partition. It's not recommended, but I'm sure somebody's doing it. Otherwise, you could use two boot partitions, each with a different version of Resolve, and it's own database.

You can import drps from earlier versions into the current version, either by dragging and dropping them into the project/db manager, or going through an import routine from the project/db manager. They'll be converted automatically to the current file/db format. The originals will remain "as is", whatever their format.

My "method" of backing up the database is done with the OS, drag and drop, outside Resolve. When you backup a db inside resolve, it compresses everything into a single proprietary file, and then has be "restored", from inside the project/db manager. The way I do it, you'd have to replace the current data base with the copy yourself, or create a new database, using the copy as the source. This method does require some understanding of the Resolve db filing system. The internal backup/restore routine doesn't -- it's all completed inside Resolve. OTOH, there are reports of "restore" failing, whereas simply copying folders from one place to another rarely fails.

Thanks John for this additional info.

John

Can Resolve's clone tool be used to make a checksum copy of a database to ensure the copy was completed with no errors?

I found that you can indeed copy the db using the clone tool, just select the uppermost folder in the hierarchy, and the option to preserve hierarchy. Cloning does add two small files inside the first folder, but they don't appear to interfere with operations (I deleted them).

i'm super duper safety person... what i meant by validateing the database is resotring it and making sure all active projects open correctly

the same thing that Rohit advised, save the database, restore it, check it, and update the saved version not the master

i save the database, restore it, check it, make a new database and update that

end game is making very sure the existing v14 database backup is valid and workable before moveing on, not assumeing that because you have backed up the database that the backup is actualy a workable backup

i'm assumeing the backed up databse is garbage - until proven incorrect

Thanks. Are you saying to export the 14 database and then restore it to 14 ( I suppose by creating a new empty datatbase and restoring it to it). Seems if you wait till you've installed 15 it will be too late, as 14 will have been uninstalled (and if the backed-up 14 database has problems it will be too late to re-export a new version). Or am I missing something?