@Photoman43 I believe that this topic was created by @platypus to explore whether it is possible to have two databases and one source of data, e.g. on a NAS and process the data successfully from either machine, albeit carefully.
I made some tests where I was not processing the data “carefully” but had both systems accessing the NAS at the same time, with automatic sync of the DOP and metadata turned on. Those tests initially performed well but something then went amiss that I need to review carefully. However I then repeated the test with additional components and wound up with the results I documented above (which might also have been what happened in my original tests).
Th bug that I “found” is a rather profound error where for one reason or another DxPL decided to put the metadata of a Virtual Copy into the metadata of the one “real” image, the [M]aster. I believe that a ‘Virtual Copy’ should be just that “virtual” and that includes the metadata, i.e. image edits and metadata should remain in the database and the DOP!
If a user chooses to copy the metadata from a VC to the [M]aster then that is a legitimate user action but DxPL deciding to “arbitrarily” do that means that there is some very dubious code in DxPL, i.e. a bug and I will formally report it for as much good as that will do!
DxO are currently pre-occupied with getting version 7 ready for release because it is that time of the year!
With respect to ‘Unwanted Virtual copies’ there was a post that ran for a year and DxO never chose to intervene and explain exactly what really happens, and I find that an awful indictment of DxO and that was before they basically vanished from this forum after the release of DxPL6.
The “Unwanted Virtual Copies” topic was here Unwanted virtual copies and the first post in that topic was also from @platypus.
This was correct but didn’t have enough detail to stop the next 83 posts over the following year until I conducted some experiments and determined the exact reason Unwanted virtual copies - #86 by BHAYT.
The database allocates a unique number, a UUid to the database entry for any newly discovered (imported) image and this is UUid also copied to the DOP, i.e. the database entry and the DOP match and are in sync at that point in time.
If DxPL ever detects that the DOP has been updated (by timestamp I believe) it checks the UUid as it imports the updated edits and if it does not match the database entry UUid then a Virtual copy will be created, referred to by most users as an “Unwanted VC”, to preserve both the original (database) edits as the [M]aster and the new (DOP) edits as a VC, typically VC [1]!
I undertook some more testing in Unwanted Virtual Copies and Moving DxPL edited images (DOPs) between System - Revisited and discovered that DxPL used the DOP UUid when encountering an image new to the database in all cases with one exception, if the UUid is already in use in the database, i.e. UUids must be unique to a database!
Whether earlier releases of DxPL always allocated new UUids I do not know but it now seems the case that DxPL will use the UUid of the DOP providing that it is unique to the database.
So when a DOP is encountered in a “new discovery” situation DxPL will use the UUid in the DOP when creating a new database entry UNLESS that UUid is already inuse. In my tests that happens frequently because I tend to use the same images and DOPs but located in different test directories for my tests so each will have its UUid replaced with a new unique UUid by DxPL.
However, that is not typical in normal circumstances and even when it happens is not a problem unless that data is taken back to a system where that entry is already in the database. If the trip to the other system has resulted in some images having their UUid’s replaced then they won’t match the database on the original system if they are taken back to that system (and database) on the same disk in the same directories.!
While my situation occurs because of image/DOP re-use it can occur if images or directories are renamed outside DxPL. The original image entries will remain in the database because DxPL was not party to the renaming/moving process. Now those images and more particularly their UUid’s will “block” the incoming images in their new location and DxPL will allocate a new UUid to any such entries to overcome that problem.
This is actually not a problem unless those images return to a system which already has database entries for those images with the original UUid.
At various points in your description of your workflow is seems that images (and their DOPs) are changing location both between systems and also within a system.
If any such change causes previous entries in the database to be orphaned they will cause any re-introduced images to be allocated a new UUid.
That will not cause a problem on that system but will cause a problem if they return to the original system.
I believe your workflow on the desktop is causing a change to the UUid’s of data you intend to return to the laptop! Exactly at which stage I cannot be sure!
This is fine because the problem only occurs when returning images located by DxPL(Laptop) are in their original location (disk and directory) and the UUid has changed and is now no longer in sync with the database.
If the location is not the same, i.e. the disk and/or the directory have (been) changed then no such “clash” will occur! Other users “trash” (delete) their database on a regular basis to avoid this problem.
Losing (“trashing”) a database is a problem if ‘Projects’ are being used but ‘Projects’ are not carried from machine to machine in the DOP anyway so they have to be set up on each machine independently, or not used at all! That will also happen if the image location is changed because the ‘Project’ pointers will no longer be valid!