I will start a new fresh database from scratch with PL6. No import, everything from scratch inside photolab.
So I will use about every existing metadatas and keywords for indexing. I will use extensively projects too, now we have a way to organize them.
I have 2 main questions :
1 - COMPATIBILITY :
What to do and what not to do, to get this database as compatible as possible with other softwares. Are there some incompatibility issues ? what are they if any ?
2 - EXTERNAL DRIVES :
I work with several external and removable drives for photography, and not all are plugged at the same time on my worstation.
a) Will photolab keep trace of every data when plugging, unplugging, changing extrenal photo drive ?
b) I would prefer to put each cache and database folder on each relevant drive. Is there a problem with this (except the need to configure photolab config file pathes everytime external photo drive is changed) ?
c) What if I need to move (or copy) some images from one drive to one other (when both are plugged) ? is there a way to copy metadatas and projects datas too ? ( is copying .dop and .xmp files with raw enough ?)
Thanks for your responses.
PLEASE, THIS IS A THREAD ABOUT HOW TO USE PHOTOLAB, SO DONâT EXPLAIN HOW TO USE OTHER DATABASE SOFTWARES INSTEAD OF PHOTOLAB HERE.
Three question, one answer: PhotoLab 6âs database is only compatible to PhotoLab 6.
PhotoLab is made to be used on one drive mostly. Copying database files to and fro is asking for trouble. Same for having your photo archive on more than one drive. Many posts out there explain why, search the forum! Best practice: Leave the database and photo archive on one drive or one drive each. Everything else is backup.
@JoPoV one of the most important things is whether you are running DxPL(Win) or DxPL(Mac) as my post identifier shows I am running a Win 10 system and any tests I carry our will be pertinent to that platform and may or may not be relevant to the Mac!?
The database is SQLite (like most of the other such software that uses a database) and as @platypus has stated relevant only to DxPL.
I think that it does but that may actually work against you just depending on the workflow that you want to employ?!
There have been requests in other posts on the forum asking for a similar feature! My concern is that it potentially adds even more issues with drives coming and going because now there is a DxPL database doing the same!
I actually believe that DxPL can handle even the same (named) files, in the same (named) directories on two different drives connected at the same machine connection with the same drive letter! But as @platypus has stated there are potential issues and the DOP and any Xmp sidecar file are all that is at your disposal!?
âProjectsâ cannot be dumped out and read back in so they will remain in the database in which they were created!?
So I decided to try an experiment as follows
Database hosted on a ânormalâ drive, the E: drive in my case which is my âextensionâ to the C: drive, both of which are SATA SSDs.
Files on âidenticalâ USB3 connected drives, i.e. same named files and held in identical directory structures. Drives were âoldâ, smaller SATA drives connected via USB3 to SATA convertors, labelled âVERTEX 4â and âINTEGRAL 2â to create a potential âworse caseâ scenario if any confusion is to exist!
Started to experiment on my Win 10 system! The files were two JPGs and 3 RAWs and they were âdiscoveredâ in PL6.2.0 in the order âINTEGRAL 2â JPG then RAW followed by âVERTEX 4â JPG and RAW.
Create 6 projects that contained
1 INTEGRAL 2 JPG and
2 INTEGRAL 2 RAW,
3 VERTEX 4 JPG and
4 VERTEX 4 RAW and
5 all JPGs and
6 all RAWs,
i.e. 2 pairs of âProjectsâ (4 in total) specifically with only files from one or other of the two drives and 2 projects which contained mixtures from both drives!
The database âItemsâ structure with all 10 files having been discovered:-
The âUniqueIdâ is related to the Volume Id. of the device and controls how DxPL âmatchesâ the directories (folders) on the device with entries in the database, i.e. not just by drive letter but by the âVolume idâ ('UniqueId) I believe! Please note the designation of âEFDOPVolumeâ for these entries in the database.
The 6 âProjectsâ to be used when a device or devices are absent and are re-discovered to see how DxPL handles such a situation:-
By using âProjectsâ it is possible to check if DxPL is handling the âoriginalâ database entries for the directories or rediscovering them anew!?
There are warnings but nothing particularly dramatic, at least not during my testing!
The database after the drives have been disconnected, re-attached with different convertors and âforcedâ to have different drive letters!!:-
To stress DxPL âa littleâ I changed to older convertors and forced the attachments to be assigned different drive designators and everything worked as it should, I am glad to say!
This test was with a database not co-located with any images because the images were mounted on removable devices. If you start co-locating with the data (not really a problem) but using removable drives then there will always be issues when the database you were using is not to be found because the drive is not attached.
At that point DxPL will create a new database and place it in the default location and you will then need to switch to the database on the drive which is actually attached!
With respect to copy/moving files between the drives then the danger has been covered many times in the forum under the banner of âUnwanted Virtual Copiesâ. This can occur when the following situation is encountered
DxPL is encountering a directory (folder) which has exactly the same name as one already in the database. As the above tests have shown that must include the âVolumeIdâ (or so my tests seem to show).
The Uuid in the DOP of a file already in the database (on the same Volume, with the same hierarchical structure) must match the Uuid of the DOP otherwise the ânewâ DOP data will be added to the database as âVirtual Copyâ [1] and the original database entry will be designated as [M]aster!
It is for this reason that I deliberately set out to make the structures on both the test SSDs identical so that I could test to make sure DxPL(Win) did not get confused and start creating unwanted VCs.
Before I try testing any further, i.e. adding the databases to each SSD I would like more than a set of âwishesâ that seek to allow you to make decisions about you work flow later, I guess that you may want to move the drives between systems?
So please try to target my testing to what you believe is the most likely workflow that you want to adopt so that I can try to replicate that as closely as possible, if I feel up to testing any further! The testing takes a little time but the write ups take a lot longer (and the re-tests when something unexpected goes wrong!).
I have two near identical systems which I can use to test a scenario that involves moving drives between systems where there is a real danger of âUnwanted Virtual Copiesâ and moving files with the database between systems where there is âŚ? I tested that situation some time ago but was unaware of the âVolumeIdâ at the time so those results are extremely suspect!?
On my Main machine I moved the database location to the INTEGRAL 2 drive and loaded an âemptyâ database.
I then recreated much of what was done in the previous tests but only using images resident on INTEGRAL 2. This included creating appropriate âProjectsâ and I then closed DxPL(Win).
I then copied the database from the INTEGRAL 2 drive to the VERTEX 4 drive, simply to reduce the steps necessary for the test!
I released INTEGRAL 2 from the Main machine and opened PL6.2.0 which could not find the database (on the removed INTEGRAL 2) so it automatically created a new one at the default location! I then specified the location of the database on VERTEX 4 and closed and re-opened DxPL and it found the database (which had originally been setup on INTEGRAL 2, in this case).
I added the images from VERTEX 4 and created additional projects before closing DxPL and releasing VERTEX 4 on the Main machine!
At this point the VERTEX 4 drive contains a database and image files with the database containing entries for images on both the VERTEX 4 drive and the INTEGRAL 2 drive.
The VERTEX 4 drive was closed and released from the Main machine and plugged into the Test machine where DxPL was re-configured to expect the database on the VERTEX 4 drive (after a restart). The main difference is that without any cached items we have the following on the Test machine.
So @JoPoV you can certainly do much of what you ârequestedâ on Win 10!
Currently I have not tested keeping the âCacheâ on the same drive and need a potential workflow to fully determine what is and what is not possible using this scheme with respect to moving images between the two drives, i.e. between INTEGRAL 2 and VERTEX 4 in my test case!!
Please remember that opening DxPL on a machine where the last drive used is no longer present, i.e. a removable drive, will result in DxPL automatically creating a new database at the default location!
@JoPoV you were starting a thread in Mid January and after that abandoned it for 2 ½ months. I donât want to judge, f thatâs polite, helpful for you or respectful to the ones replying. It just raises the question: how much time can you spare to build up this fragile thing DxO calls a âdatabaseâ? Or anything else along this line?
@JoPoV Glad you are still with us, ignore @JoJuâs âindignationâ on my and @platypusâs behalf and in particular ignore the comments about the fragility of the DxPL database, which is not especially âfragileâ at all but has its design âwrinklesâ and one of them involves the use of the âVolumeidâ.
I believe (but no-one from DxO has ever explained the exact reason for the use of the field) that it is present to allow USB drives to come and go without confusing their contents with any other drive that might have the same directory structure and the same images, e.g. a backup drive. DxPL will treat each copy as independent and there will be entries in the database for each and every copy carefully managed by DxPL and the âFoldersâ structure.
The database can be abandoned at any time since the DOP carries the necessary data to re-create the individual image and folder entries but not any âProjectsâ. âProjectsâ only exist in the database and cannot be saved and recreated/reconstructed in any way, i.e. the database is precious for the preservation of âProjectsâ.
Please identify whether you are using DxPL(Win) or DxPL(Mac) because there are differences between the two products and where it is possible to move the database location about on Windows it is not possible (I believe) to do the same on the Mac (and as my forum id. indicates I am a Windows user).
If you were not as busy to write endless manifestos @BHAYT you might have discovered one sentence of @JoPoV :
This and your âdatabase can be abandoned anytimeâ donât go well together.
Do I have to tell you everything? Oh, and itâs ok to ignore my indignation on your behalf, you would write two more chapters if thereâs a living being around you could suspect as a potential reader - just donât speak for @platypus as well keyboard-addict as you might beâŚ
Itâs ok you donât want to judge, because you donât know me neither my life.
Anyway reading some of your posts, it seems youâve become a big troll on this forum âŚ
Please, donât respond, I probably wonât have time to read more for a long time anyway.
Oh, and itâs ok to ignore my indignation on your behalf, you would write two more chapters if thereâs a living being around you could suspect as a potential reader - just donât speak for 
keyboard-addict as you might beâŚ