Just checked it - it works indeed (PL7.3/Win). I usually renamed raw files to include ShutterCount, but sometimes I forgot to run the script before loading them into DPL. In that case I modified filenames later and also changed ‘Name’ settings in the DOP files. So, the latter step is not required.
Thanks for pointing that out.
Renaming or moving files
Thanks. I’ll have to dig into the topic deeper. There’s also this “Unwanted Virtual Copies” thing…
Mr P: Would you please remind us as to what details are not held in the database (?)
Because, if one doesn’t care about those specific details then it can be far simpler to not depend on the database at all - and to simply rely on the (far more robust) sidecar/.dop files instead.
For example, I delete the database at the start of each new session - using a “wrapper” that does so before invoking PhotoLab … This works very well for me (but may not work for those who depend on some details not held in sidecars).
@John-M , your question and quote seem to address different topics, so I’ll try to comment on both 
Differences between the database’s and .dop’s content depend on OS and version of DPL used. What exactly is lost when the database is deleted has been mentioned in posts before. Just be sure to check the version of DPL used against the one commented in the post(s).
The creation of orphaned asset references depend on how images are moved or renamed - and how many times they are moved or renamed, which could also be a question of timing. Quit out of DPL and rename the root folder of the photo archive to start the mayhem…
Whether deleting the database is a viable option or not depends on whether one wnts to a) just edit images (your case and mine) or b) also manage images using DPL’s search. Deleting the database voids option b), renaming files harms option b) too, so, managing images with DPL is like skating on thin ice.
Well, how should one manage images more robustely? Use some other software (I use Lightroom, others use other apps) or don’t manage your images at all and hope to remember where that one shot of interest is hidden in a heap of thousands. How about inherited images? The classic shoebox can easily be searched, but what about the digital shoebox? Will it die with us?
Thanks …
Yes, t’was a question and a comment.
I asked that question because I’m not clear on the complete answer - - It’s certainly the case that Sidecar/.dop files do NOT retain key-words, nor details of any project membership … but I’m not sure what else they don’t hold (and, therefore, what would be lost if the database is deleted).
Following my question I was then intending to explain why I asked the question - for others to consider the pros and cons of my approach (which is to ignore the database).
BTW: In terms of finding images - I use a different (simpler) approach to keywords;
I’m sorry to have to contradict you but, keywords and their hierarchies are written to DOP files and can also be written to XMP sidecars.
Wow!!! Now that’s what I call hard work. Doesn’t Windows have the concept of searchable tags, like macOS does?
OK - there you go ! … So, what’s NOT written to sidecars ??
[I’m asking so that others (who may be reading this thread) can make up their own mind about the worthiness of the database.]
Not at all - - I have appropriate (techie!) tools … but not the type used by the general punter.
The “problem” with searchable tags is that, like keywords, one must apply them diligently and consistently in order for them to be of any use, which is not a process I can be bothered with … But I’m not disagreeing with others who can (be bothered) and who do.
On windows, history is only written to the database. On Mac it is also written to .dop files.
Wow. This is so incredibly resilient, it just takes my breath away 
Who would have thought that a simple renaming of two independent files laying somewhere on a hard drive would lead DxO to accept one of the files as the developing recipe of the other? I’m blown away. Just as I finished laughing about Capture One laying off some of their hot air generators (aka marketing dudes) you come up with this. I’m shocked.
Next stop for DxO will be civilisation of Mars, right? 
Sorry, don’t take that seriously. I found it funny… 
especially that bit of an app happily accepting a coincidentally consistent renaming process. 
I just tried to picture it and had the next laugh attack.
Glad, you had a good laugh, @JoJu , laughing is good for one’s health,
But whatever we think, feel or write here, the question “sidecar or catalig?” is worth being answered.
PhotoLab creates the database whether we like it or not. It serves a purpose, but it’s not managed properly for reliable use. Sidecars, on the ither hand, have evolved into a kind of distributed backup, but again, they are not done to fulfill the task of a backup completely.
Using sidecars helps to reduce damage, should the database go boink, but no matter what, some damage will remain (e.g. history and projects).From an asset management point of view, PhitoLab is not ready for prime time yet, but I’m afraid that DxO will not address this situation soon.
Lots of "but"s in this post 
You could replace “but” with “and”, as all buts add up.
But what is the database good for? As I understand it, no customer uses “projects” anyway, so why maintain a data tomb?
One thing I had forgotten was dops are the only way you can pass on editing you have done. Support ask for them if there’s an error without them there is no was of passing on that information.
Yes, I agree - It’s an excellent outcome.
Tho easily tested, it’s not immediately obvious to the technically-inclined amongst us, due to the embedded filename in the sidecar/.dop file (referencing the associated source-file) … as @Wlodek noted in his feedback;
It’s useful during the editing process - as it retains all editing/correction details for the current session - - and thereby enables any/all Sidecar/.dop files for the current session to be rebuilt.
Leading from this, one can delete all Sidecar/.dop files related to the current session, and PL is smart enuff to notice and simply regenerates them.
That’s interesting. With “session” you describe the time span from starting DxO PL until shutting it down? I never observed some folders related to DxO to see what’s going on and where.
In C1 terminology, a “session” remains as sort of miniature catalog even after shutting down the app. I’m not sure about that as I never work with sessions. So I checked.
Use the Sessions function to organize all your work and any client project. Sessions enable you to store all files as a complete project that includes RAW files, setting files, library files, output files, and paths to drives used in a project. For quick access and fast loading of folders, you can create favorite folders for the locations used in a particular project.
So, it’s rather different, but as DxO has no tethering support (to my knowledge) I think your use of “session” comes closer than C1’s definition. A C1 session can last hours, but also days and weeks, No matter how often C1 has to be started. I would call it single project vs multi projects.
Initially C1 was developed for PhaseOne MF camera use in studios,
mostly for fashion, glamour, portraits, advertisments.
It was “tuned” for the sensor and this type of photography.
Typical session spanned several hundred photos, of which only a few were chosen
for later postprocessing by the designers.
The same C1 instance could have been used by different photographers,
using their various presets. Hence the initial concept of C1 “session”.
The DxO main database stores ‘history’ on Mac but not on Win (PL7),
so it’s better to specify which database we are talking about.
For Win at least, DxO should “denoise” the ‘history’ to make it useful.
I only use DxO PhotoLab to develop my RAWs into JPEGs. It does a fantastic job of that, but it’s an utterly crappy image manager. For sorting and organizing my photos (and video clips) I used to use DigiKam but these days I usually use XnView MP.
My sidecar/companion file setting are “xmp;jpg.xmp;dop;arw;arw.dop;arw.xmp” (+the other RAW formats) so I only see the DxO-developed JPEGs, and the RAW files and their .xmp and .dop files are moved, renamed and deleted together with their .jpg like bundles.
I have one purpose:
Exporting a set of images to be progressed from say Bridge (DAM) to dxopl.
So if you use a external dam instead of the internal of dxo for keywording en xmp writing projects are nice to have.
I don’t need to keep them after i am done editting the project may deleted as grouplist.
I’m sorry, @OXiDant I wasn’t able to fully understand your text. So I put it into DeepL to translate it with AI and after that using my UI (unartificial intelligence = my two braincells collaborating… 
) and here’s what I think you could have meant:
I have a suggestion:
I export a series of images to process them from Bridge (DAM) to dxopl.
So if you use an external DAM instead of Dxo’s internal one for keywording and xmp writing projects are very useful.
I don’t need to keep them after I’m done editing, the project can be deleted as a group list.
At first, Adobe Bridge is primarily a viewer. I had some really bad experiences with it during the past years alone with colour tags (like PNG losing them after editing in PS). So, at home strictly no Adobe products!
I think, you’re referring to Bridge’s “collections”? Yes, for temporary tasks like collecting some images together, working on them and afterwards deleting the collection (as containment) that’s a way to go. Problem is only, there are no hierarchical structures, meaning, after a while the vertical list of collections gets very long. To find a certain collection it takes a while to scroll and read a lot of collection names.
Never mind, DxO is not made with good DAM intentions in mind and Adobe Bridge falls short and comes from a company I consider as greedy and less reliable in terms of file handling. Working with databases needs a bit more than nerdy geeks playing buzzword bingo. But for short, quick & dirty selection collection without moving files around, your suggestion is fabulous.