Help, keywords lost after deleting child categories in data driven @Keywords

[jarraun]

Hi,

I was trying to organize the mess in the data driven @Keywords category, I thought that deleting all the child categories in @Keywords and then  refresh @Keywords would do the thing. Surprisingly for me what I did was to delete all the keywords from my images, now they have the yellow pencil telling me that I must write {File.MD.XMP::Lightroom\hierarchicalSubject\HierarchicalSubject\0} and {File.MD.XMP::dc\subject\Subject\0}. Restoring the database with Pack and Go doesn´t help, keywords doesn´t appear. I attach the IMatchPackAndGo text file.
Please how would I recover my lost keywords ? 

Sad Regards

Javier

[attachment deleted by admin]

[joel23]

Hi,

I was trying to organize the mess in the data driven @Keywords category, I thought that deleting all the child categories in @Keywords and then  refresh @Keywords would do the thing. Surprisingly for me what I did was to delete all the keywords from my images, now they have the yellow pencil telling me that I must write {File.MD.XMP::Lightroom\hierarchicalSubject\HierarchicalSubject\0} and {File.MD.XMP::dc\subject\Subject\0}. Restoring the database with Pack and Go doesn´t help, keywords doesn´t appear. I attach the IMatchPackAndGo text file.
Please how would I recover my lost keywords ? 

Sad Regards

Javier

If you still have the original DB (those with the yellow pencils) I would void writing the data back by marking all files with a pencil and using Database -> Database Tools -> Clear Processing Queue -> Clear metadata write-back queue. After that do a manual reload metadata which should bring back the keywords. If not, try a "force update".

But restoring the database should work or you also need to reload metadata here.

[Mario]

1. When you work with @Keywords, you are working with the actual keywords in your files!
Making changes in @Keywords is automatically mirrored by IMatch in the keywords in your files.
See the help topic on @Keywords to learn about how this works.

2. Until the data has been written back, no changes are made to your files. If you see the yellow pen, the data has been changed in the database only, but not in the file.

3. To restore the data, just select the files and then press <Shift>+<Ctrl>+<F5>. In the dialog, choose "Reload Metadata".

4. Before you do 3, check under Edit > Preferences > Metadata 2 that the protection settings are off. Otherwise IMatch will re-import the XMP data from the files, but protect the pending keywords and not replace them from the keywords in the files.

5. If you do something in IMatch by accident, use Edit > Undo the next time.

[jarraun]

Buff....

Thank you Joerg and Mario, I have only tried Mario´s method and seems to work as far as I can see. I had no played enogh with @Keyword data driven category and I´ve been too impulsive and of course awkward. What puzzles me is that restoring the database haven´t worked in this case, could please someone explain that ?

Glad Regards 

[joel23]

Buff....

Thank you Joerg and Mario, I have only tried Mario´s method and seems to work as far as I can see.

Basically it's the same, except that I forgot to mention step 4 

What puzzles me is that restoring the database haven´t worked in this case, could please someone explain that ?

Guess it's hard to tell without further information. Maybe you should let us know what exactly you have been doing, step by step.

[jarraun]

Joerg,

Apparently in my Pack and Go Backup I do the standard process and always diagnose and optimize my database when packing. Only perhaps one of this two facts could affect:

- My last Pack and Go Backup was made with version 5.2.4 and the restore was tried with version 5.2.6
- I remember having changed my database.imd5 file from the HDD to the SSD of my PC and also changed its name with Windows.

I don´t know if any of these things could affect the Pack and Go Restore process. Maybe someone is able to come to a conclusion by opening the IMatchPackAndGo text file attached in my first post.

[joel23]

Joerg,

I don´t know if any of these things could affect the Pack and Go Restore process.

No, I don't think so.

Maybe someone is able to come to a conclusion by opening the IMatchPackAndGo text file attached in my first post.

I just saw it now in the log, that all files were skipped. Seems you tried to restore to the original location? Have you close IMatch before doing the restore?
Try to restore to a different location.

[jarraun]

Thanks again Joerg,

Seems you tried to restore to the original location?

Yes I did, I think it´s by default. Must I select restore to a diferent folder ?

Have you close IMatch before doing the restore?

Yes I did, I think restoring is only posible with IM5 closed.

Try to restore to a different location

I will try later, but I don´t understand this sentence from the help:

Restore to a diferent folder
.... allows you to restore multiple packages into the same output folder. This mode enables to you extract a package and to review and restore individual files

[joel23]

Thanks again Joerg,

Seems you tried to restore to the original location?

Yes I did, I think it´s by default. Must I select restore to a diferent folder ?

It's not a must - but you can do that in case you only want to use a single file from the restored package, for example only the DB.
What to do IMHO depends on what happened and what your goal is. When - like here - only the DB (almost) has been changed, you might not want to overwrite other files like the settings DB, annotations, dictionaries, etc. pp. - especially not when the backup is a bit older and those other files might have been changed in meantime.

btw: when you tried the first restore, can it be that you had checked "Don't replace newer files"? This would explain while all files were skipped.

I will try later, but I don´t understand this sentence from the help:

Restore to a diferent folder
.... allows you to restore multiple packages into the same output folder. This mode enables to you extract a package and to review and restore individual files

See above at the same page:

Restoring to a Different Folder
If you restore a package to a selected output folder, Pack & Go creates a sub-folder hierarchy below that folder which matches the folder layout in the package. You can then view and access individual files using Windows Explorer or other software.

Use this mode if you only want to restore selected files.
Unpack to a temporary folder and then copy the files you're interested in to their final destination using Windows Explorer.

That explains it much better, I think.