Batch update .dop sidecar files

DxO PhotoLab
1

I’ve written about this in a different post, but cannot find it any more. Moreover, I’ve streamlined the process and decided to let you know.

  1. in DPL, create a backup of DPL’s database
  2. open the backup DB with a DB browser like “DB Browser for SQLite”
  3. create an SQL statement (as shown below) and run it
  4. save modified backup as a new file
  5. restore DPL’s database from the new file created in the previous step
  6. wait until done

Conditions

  1. DPL is set to automatically import and export the .dop sidecars (DPL default)
  2. The SQL statement for DPL on macOS is
UPDATE ZDOPSOURCE
SET ZSIDECARNEEDSTOBESAVED=1

Updating 25k records took about 30 seconds.
If you don’t want to update ALL .dop sidecar files, append a “WHERE” statement that limits the scope according to your needs.
YMMV with DPL on Windows (different table and variable names)

Tested with DPL7 and corresponding backup. Modifying an older database can restore conditions e.g. for cases of extensive testing of a trial DPL or to eliminate settings done by new features. Just take care in cases where the “old” backup was done too long ago. It helps to make a backup BEFORE new versions and features are attacked.

2

Hello, Mr P.

After “reading a little between the lines”, I gather your process results in flag being set to force generation/update of sidecar/.dop files for all images in the database (?)

Are they generated/updated the next time that PL is pointed at each specific folder ?

John M

3

@John-M Exactly!?

@platypus for Windows PL9 the syntax is slightly different

So before we have

2025-11-17_105747_
2025-11-17_105747_1920×627 215 KB

The SQL submitted with PL9.2.1 closed and with the database sitting on my N:\ drive, a fairly fast PCie4 NVME

UPDATE SOURCES
SET SIDECARNEEDSTOBESAVED=TRUE

2025-11-17_110320_
2025-11-17_110320_808×1744 96.7 KB

14,945 ‘Sources’ rows updated in 0.102 seconds

The results

2025-11-17_110403_
2025-11-17_110403_1920×511 169 KB

@platypus The database is now “armed” what comes next to trigger the creation of “wall-to-wall” DOPs?

and I presume the same thing can be done with ‘MetadataNeedsToBeSaved’!?

Plus doing it on earlier release databases means that you can selectively import that data into later releases or empty databases running later releases which has merit for testing, I think!!??

Plus, Plus You run your PhotoLab typically with the save and read DOP options set off, mine are typically the reverse so PhotoLab is creating DOPs all the, not actually true because it is possible to open a directory in a new release and DOPs are not automatically updated etc. etc…

So what happens if you set the flags on but have the options turned off?

4

The sidecars start to be exported right after you have restored the database from the modified backup. No need to point anywhere. When I tested, I had selected an empty folder to make sure that there is no need for clicking or re-indexing.

5

Did not test that config. It could still work as expected as PL imports the files as new. Maybe it’s necessary to trash the DB ahead of the restore, maybe not.

Update: The “auto-export” box must be checked.

This sort of updating sidecars is meant to be a step to make sure to save sidecars so that the respective info is up-to-date. The most obvious use cases are for database cleanup (write all dops, delete the db and index the whole load to get rid of leftovers) and to prep for new version trials (which should be done with a separate set of copies) or as a fix of such trials if one has tested with “the real things”.

For the good of everyone interested, it would be helpful if someone on Win could test this and write about it.

1 Like