is it problematic to use 17.1 and 17.0 on the same database?

title says it all.

so far we have had alot of "critical errors", mostly when saving projects. 1 project even vanished into the oblivion. It might be a coincidence that this is happening since we upgraded to 17.

it's a disk database, placed on the NAS, and we use both mac and windows systems. We never use the projects on multiple systems at the same time, as i am aware this is something which requires an SQL database.

we have used this disk database method with resolve 16 before without these issues. We use similar workflows for other software as well, without issues.

is it required to use the exact same version?

I think my choice would be to switch to a PostgreSQL database and update the second machine to 17.1. I would only use a disk database on an internal disk.

Hmm well i'm not really looking for a personal preference, more like a "yes" or "no"

OK.

No. Switch to a PostgreSQL database and update the second machine to 17.1.

Don't know about your 17/17.1 question, sorry, but are you aware that the Resolve disk db file is actually a 3.31 SQLite database file?

The advice from the official SQLite site under Appropriate Uses For SQLite is that accessing such files over a network share is not recommended - it's designed for local disk access:

SQLite will work over a network filesystem, but because of the latency associated with most network filesystems, performance will not be great. Also, file locking logic is buggy in many network filesystem implementations (on both Unix and Windows). If file locking does not work correctly, two or more clients might try to modify the same part of the same database at the same time, resulting in corruption. Because this problem results from bugs in the underlying filesystem implementation, there is nothing SQLite can do to prevent it.

In another article under How To Corrupt your Database Files, they say:

Your best defense is to not use SQLite for files on a network filesystem.

The fact that you have got away with it up to now is not proof that what you are doing is a safe practice even if you have the self-discipline to not try to open the file on more than one machine at a time. A crash (not unknown in Resolve!) on one machine - or network issues - might leave the db locks and temp files in an inappropriate state which causes problems when the other machine tries to open it up again.

Another potential culprit for this type of occasional file database problem is over-zealous antivirus software putting temp file locks on the db file (or associated temp files) while scanning. Could that be a thing for you? It might help to set up an exclude rule in your AV settings to ignore the Resolve db folder on the NAS, if you haven't done so already?

You could also try creating a Resolve log file from the Help menu and dig through it to see if it tells you anything useful about the crashes. They are pretty verbose but they may have something in there to point you in the right direction.

The bottom line is that for safe shared db network access you really should consider moving to a supported PostgreSQL database solution.

[Peter Chamberlain]

17.0 and 17.1 have no database difference so you can share one DB with these versions.

The issues you have are likely NAS related.

Thanks bobosola, that is pretty much out of the blue for me, but very helpful

@Peter;
Do you agree with bobosola about this, that it is in fact not a great idea to use a disk database over the network?

[Peter Chamberlain]

It’s advised to use on a permanently connected direct attached disk. Ideally internal.

I worked as a software dev for many years and worked with a lot of databases. The big beasts designed for multi-user use (MySQL, SQL Server, PostgreSQL etc.) never caused problems. It was always customers trying to save money by using databases designed primarily for single use (but capable of small-scale sharing) which caused occasional problems over a network (MS Access, Filemaker etc.). While I haven't personally worked with SQLite, it's a very well-respected database engine used worldwide, but it's designed primarily for local data stores on the same disk as the application.

Local database files are complex. Apart from the main data file, they usually have associated temporary files which control user access to data while it's being edited (data locks), and can also have temp files for maintaining data integrity for crash protection (rollback journals). These are controlled automatically by the software and are created, edited and deleted by the software itself. You usually won't see them unless you've had a crash.

If anything external gets in the way of these processes, such as AV software scanning locks, slow network, network permissions problems etc. then you can suffer anything from a failure to save data to a full-on data crash. So it's best to keep such database files local and single use as the designers intended.

Other file types are much less susceptible to this kind of problem when shared over a network as there are usually no associated complex processes of automated data access locking, journalling etc.

Should have added (with apologies if you already know about this and are doing something similar):

A possible safety workaround for you might be to use the built-in Resolve feature for incremental project backups - but ensure the path on each machine is set locally. That way, you would have an up-to-x minutes backup on both machines in case the shared NAS copy crashes again.

You can restore from these project backups (from whichever machine was used last) by right-clicking the project in the project manager. The manual has a full explanation under "Project Backups"

Screenshot 2021-03-22 at 13.46.33.png (73.95 KiB) Viewed 4310 times

The project backups don't include media files so take up very little room. And the system automatically deletes older copies which have fallen out of the scope of the settings above on a first in, first out basis.