This may have been answered before, but I could not find it so I ask…
I have just installed a new 2TB SSD on my PC. As I write this my PC is busy copying all the photos and the sidecar files from the HDD to the new SSD. It may take a while, it’s a close to a terrabyte of files… some 160 000 photos.
But I have to “inform” the PL database that the location from now on is on the SSD. What is the best way to do that?
If that SSD drive is your new drive that contains the images, then I would delete the database and start from scratch. If you use PL also as a DAM then you’ve to index the files. Can take a while.
You don’t have to inform PL. When you open a directory it builds/updates its database
That are my thoughts. Don’t rely on it.
What bone? Windows or Mac?
On Windows, if you keep the same disk letter and the arboresence of the files doesn’t change, that will not have an impact.
The deleting of the database leads to the loss of certain data such as the project and the color tag and perhaps even something else …
I will still have my old HDD installed. The SSD gets another drive letter. Since both directories are identical after the copy, I would prefer to change drive letter in the DB without index it all again…
The heading was “PL7.1.0 (Win) Issues when changing a drive” perhaps I should have made it " PL7.1.0 (Win) Issues when changing a drive/Moving photos from one drive to another".
@Franky sorry if I have read your posts correctly what you have written is incorrect, the drive letter is immaterial for conventional drives what matters is the drive id, serial number …whatever you want to call it.
This is the controlling identifier in the DxPL database and needs to be “hacked” I am afraid!?
Arguably the same for NAS/network drives but I believe it is possible to swap them if you map the new drive in place of the old or, if both drives are staying then map the old drive to e.g. “OLD-Y” and the new drive to “Y” where Y was the original id…
So what about just deleting the db. If the drive id can’t be replaced by another, the old db is useless. Maintaining it only results in a containing for 50% rubbish.
Just take care if you’ve keywords that they are written in either dop or xmp.
@George But that isn’t the scenario being discussed here!
If you have no use for a database because the changes to the directories etc, have changed beyond all recognition then the database is useless and way to hard to fix!
But if the directories are intact and are an exact copy of the original, as mine are on my USB3 backup drives, then I could “schuck” the drive from its case and fit it in the PC or run with it as a USB3 drive but I could retain the database if it contains something useful, e.g. ‘Projects’ or don’t want to face face hours off (re-)indexing rebuilding a database when I have a perfectly formed database already except the drive ids don’t match!
It is possible to change the id of the disk itself but the OS will object to having two drives with the same id. (as will the DxPL database).
So the safer way is
Take a number of backups of the database (to provide multiple opportunities to get the hack right)
Hack the database as appropriate changing essentially one field, or two if both drives are still attached (using a dummy number to avoid the database rule that there can only be one entry with a given id. in the ‘Folders’ Table at any point in time). The details are in the topic I wrote on the subject.
I believe that there is another way to accomplish the same thing but haven’t checked all scenarios and it still requires a database hack!
It amounts to changing the ‘Id’ field so a new drive effectively “inherits” the database entries of an old drive! It should work to transfer from a NAS to a fixed drive or vice versa (but only if it works, which I believe it did in testing for a specific scenario).
In addition where indexing was not a disruptive process on PL6 on DxPL(Win), it is as of PL7, once started DxPL is out of action until indexing is finished or cancelled.