@joanna hello again. The problem is that some users want to move from a laptop to their main system and then back when they want to go on fields trips. If they want continuity then the two systems need to be able to track each other and stay in Sync…
The repatriation procedure I proposed and tested is fine and works providing there are no other references to the images, e.g. ‘Projects’. Given that you can’t even back-up projects and there are no project details in the DOP (although that could be a nightmare with really old DOPs that have lain untouched for a long time, referencing long “dead” projects) so projects exist only in the database!!
So throwing away the database rules out projects, using “my” repatriation procedure rules out projects so …
While I like the proposal I put forward, to be added to a (long) list of things that might never happen, if the critical DOP Uuid survives the journey to the other system then the DOPs will return just as if they never left!?
I don’t understand why all the problems we encountered occurred and wonder if the medication I am taking meant that my recent tests were not conducted correctly but a simple “fix” for the problem is to preserve the Uuids at all costs (but that is impossible if the Uuid is already in-use on the other system)!
My first attempt was System A (my Main system) on 5.5.0 to System B (my Test System) on 5.1.4! The DOPs were not backwards compatible, no edits appeared on System B and the Uuid was instantly changed!
Cloned the Test system SSD, upgraded to PL5.5.0 and reran the tests and the DOPs came back onto System A with the Uuids unchanged or so I believe, I will rerun the tests with PL6 later today or tomorrow.
PL4 is also installed on both machines and the DOPs went from System A to System B without Uuid change (or so I believe).
If the Uuids between systems are unlikely to “clash” then many transfers should go unscathed?
Which then leaves This image cannot be processed since the source file could not be found ( After I cloned the Drive ) where on WIN 10 using a ‘Mount Point’ seemed to be the only answer. The issue here was the drive was not getting the same UniqueId = Volumeid/number in the ‘Folders’ Table in the database!
So though it appeared that the drive was back in the same place it was actually getting a new UniqueId taken from its Volume Number/Id and a new entry in the ‘Folders’ structure!
So
- No unwanted Virtual copies but
- Duplicate data in the database (entries for both copies) were being maintained in the database)
- Project references were being “broken”
So I need to repeat my tests as follows
- Clear databases on both systems
- With new images carry out my procedure outlined above(steps 1-12 in the first post) and test projects.
- With more new images repeat step 2.
- With the same images from 2 but without DOPs repeat step 2
- Find a large database in my saved list and import into PL6 and repeat some or all of steps 2,3 and 4
- Report back in this topic
- Hope that any who are experiencing problems update this topic with their current experiences!