@John7 and @John-M you are both avoiding the problem in your own way and there is nothing wrong with that and you have a workflow which neatly avoids the problem.
My alternatives (providing I have done the testing and describing correctly) also can work.
However, as I have written elsewhere @sgospodarenko, more than once the real fix is to extend PL5 slightly to provide facilities to allow replicake images to be reintroduced to the database without causing VCs, i.e. a warning and override on a
- individual
- group
- directory
- session
- preferences
etc basis with options to
- Make replicake the database entry
- Keep the existing entry and reject replicake
- Use a date timestamp with all, … to inform the user and prevent the wrong decision.
- Allow both to be kept selectively, i.e. the classic VC situation
- any other options I have missed
In the meantime keep deleting the database and avoiding the problem but there are (just) other options.
PS In the event that this happens or a user has been using VCs for evaluating editing possibilities it would also be useful to have a “promote” function to allow a VC to replace a [M]aster copy and also to allow swapping and re-organising the VCs to create an evaluation order for VCs.