Moving disk databases to new PC

I am in the process of moving to a new PC, as my 10-year-old Fujitsu needs replacement. What is the recommended way of moving the disk databases.

- Backup and restore from the Project Manager
or
- Just copy the folder where the 2 disk databases resides

All source files will be at the same location on the new PC, but I would want the power bins and Canon LUTs to be moved as well, if possible.

Copying the entire path used to work before they switched to SQLite. It will probably work. Test it and if it fails you can also export/import DRPs. If you have a lot of projects you can use a DRP export script I wrote for my own use. https://github.com/IgorRidanovic/DaVinc ... rtProjects

You can do it either way. I assume you mean folders (plural) when you say, "Just copy the folder(s) where the 2 disk databases resides".

I would copy the database folder(s) and connect to them in the new installation, rather than go through the backup/restore routine, which can be more prone to error, but it's really up to you.

The trouble with importing .drps into a newly created DB in the new system is that you'll lose system settings stored in the current databases.

Thank you for your input on this. I will try to copy the folders and reconnect first. Seems the least trouble.
As this is non-destructive on the original computer, I see no risk with this.

- Backup and restore from the Project Manager
or

No "or", just that.

- Backup and restore from the Project Manager
or

No "or", just that.

There are interminable threads here speculating, in error, on how to manage projects and databases, and for handling problems not solved by backup/restore. If people took 5 minutes to actually look at a database, the matter would be instantly demystified.

Note also that backup/restore entails compression, and the copy/compression procedure has been known to fail on occasion. This is rarely the case with manually copying and pasting a database folder which (for the truly paranoid) can be accomplished with error checking inside Resolve.

Afraid to move and connect manually to a database? Sooner or later you'll be in trouble you won't know how to handle.

What's the great benefit of Resolve's otherwise confusing "database"?

The app needs to save the state of the project, save it dynamically, and make it so that multiple clients can read and write the information as long as they are not overwriting each others information. All this is a good fit for a relational database. Why reinvent the wheel when the building blocks already exist?

To see the advantage you could compare this with how Avid DS used to save the project file without a database. For R/W efficiency it was an incremental save. Let's say you had a single paint shot timeline. The file size could reach hundreds of megabytes as each auto save was adding to the existing file. The "Save As" would break this chain and trim the excess, but that could take a bit. Just because you had a tangible project file didn't achieve any more portability than the Resolve DRP file does.

As far as "confusing 'database'" maybe let's do a thought experiment. Forget for a second Resolve uses a database. Just think of the projects saving to a secure place. It's completely hands off. If you need to share a project file with someone you just save a DRP from Resolve. It's no different than a "Save As" in other apps. Really, the only difference between Resolve and an app that doesn't use a database is that you can't copy a project file on the file system level. That's a very minor disadvantage.

There are interminable threads here speculating

Not speculation.

"We would suggest that you mess about in the database folders at your peril." - Dwaine Maggart. [emphasis added]

Peter has said similar over the years.

There is only one 'recommended' method for handing databases - via Project Manager.

Does that mean an expert can't do it manually? No. But...you void the warranty.

Nobody said a word about "messing" with database folders, as in altering them or their content, but if you can't copy a database folder and connect to it, for fear of ruining the installation, it's pretty hopeless. You'd have no prospect of performing the most rudimentary recovery efforts when backup/restore fails, or when backup/restore is simply not germane to correcting the problem at hand, as in the interminable threads referenced above.

Then you'd post your question here, and Dwaine would instruct you on how to mess with the database folders, as he's done many times before. Believe me, it's a very simple matter, these fears can be conquered.

The app needs to save the state of the project, save it dynamically, and make it so that multiple clients can read and write the information as long as they are not overwriting each others information. All this is a good fit for a relational database. Why reinvent the wheel when the building blocks already exist?

To see the advantage you could compare this with how Avid DS used to save the project file without a database. For R/W efficiency it was an incremental save. Let's say you had a single paint shot timeline. The file size could reach hundreds of megabytes as each auto save was adding to the existing file. The "Save As" would break this chain and trim the excess, but that could take a bit. Just because you had a tangible project file didn't achieve any more portability than the Resolve DRP file does.

As far as "confusing 'database'" maybe let's do a thought experiment. Forget for a second Resolve uses a database. Just think of the projects saving to a secure place. It's completely hands off. If you need to share a project file with someone you just save a DRP from Resolve. It's no different than a "Save As" in other apps. Really, the only difference between Resolve and an app that doesn't use a database is that you can't copy a project file on the file system level. That's a very minor disadvantage.

Igor, thank you very much for explaining it in such detail!

So basically for keeping things clean in multi client use? It still feels like a relict imo and the many threads on this forum regarding database questions and confusion are quite telling.

So basically for keeping things clean in multi client use? It still feels like a relict imo and the many threads on this forum regarding database questions and confusion are quite telling.

I think it's just a matter of abstraction, or how you choose to think about the mechanism that saves Resolve projects. For most users the anxiety goes down when you remove the word "database," like BMD has done with the introduction of the Project Server.

So basically for keeping things clean in multi client use? It still feels like a relict imo and the many threads on this forum regarding database questions and confusion are quite telling.

I think it's just a matter of abstraction, or how you choose to think about the mechanism that saves Resolve projects. For most users the anxiety goes down when you remove the word "database," like BMD has done with the introduction of the Project Server.

I'll definitely try that approach.

I think the anxiety would also be less if those databases weren't automatically buried in some mysterious place on the system that many users can't even see until they make hidden folders visible.

Would be less confusing to let the user use their own folder structure and direction and, yeah, not call it "database". Average user today is a creator, not an image technician anymore

It's so simple, that the confusion is itself stupefying. Try this: forget about the "Local Database" created by the default installation and hidden away in data folders.

You're going to create your very own disk database, so you'll know exactly where it is and what's in it. Pick a disk where you want that database to reside. Using the OS, create an empty folder at the root of the disk and (if you want to make life easy) give it the name of the database (and you'll want to avoid spaces and special character).

Now go into Resolve's database manager and create a new database, giving it the same name. We're talking about two or three mouse clicks, and filling in the name field. Then browse to the folder you just created, as you'll be directed to do, and select it. Voila! A database! Now, create a project, even an empty one, doesn't matter, as long as it has a name and you save it.

Then go back to the OS, find the folder you just created and have a look at it, and see how obvious and simple the organization is. A "database" is just nested folders. Thanks to "legacy" design, you may find that stuff pertaining to your own configuration is inside the "guest" folder. But after that, it should be easy going and self-explanatory. And you'll find your newly created project, sooner or later.

This is not a recommendation to "mess" with the folders, though you can, if you have to and know what you're doing. But at least you'll see what's going on, and you'll know where to find it.

Thanks for the detailed instructions and approach. I think that alone (Resolve not dictating a hidden destination from the get go) would prevent a lot of database questions that constantly pop up on this forum. That, and that name

Manually copying the disk database worked just fine. After the move DVR only had two complaints:

Could not find LUTs. Fixed by copying Canon LUTs from my user on old PC to new user

Could not find power bins. Fixed by copying them from old to new user and updating path in project settings. I have to fix that path in each project if I need to reopen an old project. This is because my username is different on the new PC. Did not notice that when I installed it.