@mikemyers If you use Photo Mechanic then I believe there is no database but if you are using Photo Mechanic Plus, Capture one, Lightroom, Zoner, ExifPro, IMatch, ACDSee, Photo Supreme and PhotoLabs then there is an SQL database lurking underneath the product, except for ACDSee which appears to be a derivative of DBase!
Photo Mechanic, FastRawViewer, @Joanna’s product and Adobe Bridge read the data direct from the image.
Do you need to know how PhotoLab’s database works and the answer is NO, can you remove the database or make DxPL ignore it’s existence and the answer is also almost certainly NO! Does that matter and the answer is also, most of the time, NO!
Except for the one time that you decide to carry an image from one DxPL system to another, make edits and try to bring the file and its new DOP back to the first system, with the same name and still in the same directory. If that DOP is indeed shiny and new then there is a problem because the original system decides that it does not match the entry in that systems database and it will only “attach” the new sidecar as a nice new shiny Virtual Copy!!
This issue has been the topic of countless posts in a number of forum topics and still it seems to crop up. Would removing the database or not using the database prevent this problem and the answer is yes, except that nothing else would work because the database is the central storage entity of the product.
So there are two courses of action to avoid the problem, i.e.
-
Delete the database avoids the check failing but also destroys all the data in the database which for some doesn’t matter but for others would matter a lot!
-
Use a procedure like the one that I have written down that avoids encountering the problem which is so straightforward that I feel that it is a minor inconvenience to use it (except in the case of huge directories, perhaps).
Is it annoying, for a number of users very annoying but it can be avoided.
Is there a fix, well the solution I proposed earlier in this topic is not very complex to develop, essentially it just “flips” the process so the incoming DOP is taken as the [M]aster instead of a Virtual Copy and the existing database entry becomes a VC or is abandoned.
It would work and would leave the database intact, I would call that a win, win situation BUT I cannot write it, I cannot force/persuade DxO to write it and it appears that no matter how much I have written about this topic and presented a detour, the database is once again “the culprit” and I wonder if anyone has actually read any of my long posts!?
So for the last time here is the procedure to use that avoids Virtual copies and allows data to be carried from one system to another and back again and across again and… as many times as needed.
Copying from A to B where the directory and file names are on both systems and in both DxPL databases.
- On destination system B change the name of the target directory with DxPL, e.g. to “-Original” or “-OLD”.
- Copy the original directory from the sending system, A, (via a LAN using mapped drives, in my case) or via a USB stick or drive retaining its name (the original name) onto System B.
- Navigate to the newly copied directory on the target system, B, and re-discover the original named directory
- The renamed original directory can be deleted once the new copy has been checked!
To check it out I did the copy in the opposite direction taking a directory “Test - 02” back from B to A via a USB3 stick
- Copied the original directory to the stick using File Explorer, dismount USB3 drive from B and unplug.
- On A, open PL5 and navigate to “Test - 02” and change the name using PL5 to (e.g.) “Test - 02 - Original” or “Test - 02 - OLD” etc.
- Plug in USB 3 drive and copy “Test - 02” from USB3 stick and paste to the correct location on the mirror disk structure on A using File Explorer
- Navigate to “Test - 02” with PL5 (which was open all the time) all good and no Virtual Copies
- Delete the old directory as and when appropriate.
The overhead is the additional swing space needed for a “duplicate” copy of the directory on the target system.
Apart from the directory name change and subsequent deletion (which would also have happened if the copy had been over the target directory) this is identical to a normal copy except that no Virtual Copies will be created!