Merging or Splitting an IMatch5 DB

[Graham]

How do merge 2 IMatch5 DBs together into one while preserving the IMatch collections metadata, eg, labels, rating, etc?
Similarly what's the best way to split an IMatch5 DB into separate DBs preserving the collections metadata?

Cheers,

[Mario]

IMatch databases can handle huge amounts of files. Splitting a database is always calling for trouble because you will sooner or later want to re-combine them. And this is not easily done and may end up in a lot of work. Better use the built-in features to manage huge amounts of files in a single database.

You can split a database by

a) Duplicating the database file on disk.
b) Opening the new database and go to Edit > Preferences > Database and click on change database ID. This will un-link the two databases.
c) Removing the folders from the new database you don't want to manage in it (Remove folder from database command)
d) Run a Database > Tools > Compact.

You cannot merge two IMatch 5 databases. You can of course just add folders to an IMatch database and this will bring in all metadata (including rating and label), and all automatic collections. You can export categories and Attributes and re-import into another database.

I would think twice and hard before I would consider working with more than one database.

[Winfried]

Although I understand your arguments, I am thinking of a scenario where a merging of databases might be usefull:
Travelling (abroad) I use a laptop to hold my (new) photos on one or two usb-disks. I would like to assign categories and other  information.
Back home I would like to merge this database with my "productiv" database.

OK, it can be done by using the whole "production" database on the laptop and copying the database back to main system after the vacation.
But merging databases would be more easy, at least from the endusers point of view.

Winfried 

[hro]

But merging databases would be more easy, at least from the endusers point of view.

Winfried

Winfried,
I beg to differ.  I believe taking your database with you is so much easier. Doing this you can do all your work in the one database and when back at home you just need to copy your images across, your database, and then relocate the image folders. Seems to me much easier and safer than merging a database. I have been doing this for many years now and find it very convenient.

[Mario]

But merging databases would be more easy, at least from the endusers point of view.

There are  many logical and technical reasons which may prevent IMatch from merging databases, or where merging may fail or produce unexpected results. Besides the enormous development efforts.

It is so easy to take the entire database with you. A 32 GB USB stick costs 20 US$ and can hold several versions of a 200,000 files IMatch 5 database, even with cache files. And no need to merge when you are back. Just replace the old database, copy the new images, relocate folders and you're done. Copying the database back and relocating one or more drives takes only a minute.

[Graham]

Mario,

Tks for your comments.

We travel quite a lot and there isn't a real option for us to take our full DB of >130,000 images requiring >600 GB on my laptop. My usual strategy is take an empty, current version of the DB on my laptop and then merge the results, which will include new categories etc, back home. We do a lot of bird photography and as well I like to play with image stacking for high dynamic resolution and increased depth of focus. Taking 10-15,000 images in typical of a trip. Certainly a convenient and, for me, low finger-error-prone merge would be very helpful.

Further though, with your extending the scope of IMatch further into 'digital asset management', I can think of several reasons for having separate DBs and having the ability to conveniently split, copy and merge parts of DBs would be advantageous.

As an example, my wife works with the local Family History & Genealogy Society. There are several apps available promoted for family tree or history, however, these tend to have limited scope and limited options to extend functionality. I use Microsoft Access quite a bit and my current thinking is that Access combined with IMatch will be ideal. I will certainly start this as a separate DB to see how best to handle and manage the wide variety of document types and information. A work in progress.

For music libraries, there is also a number of very good apps to manage, stream, etc audio and video. I like to use Media Monkey which is excellent as a music library but with limited capabilities for extension. I also play the guitar and have a large library of music documents (including docx, xlsx, pdf), videos, audio and images with which I'm experimenting managing in IMatch5. So far it looks like to I'll be able meet my requirements. A work in progress.

Having been in the IT industry since the late 1960s, I'm a little bit wary about a single application, data base, or whatever being all things to all men. There may well be such and application but I prefer to walk before I run. During my exploration of IMatch5 as digital asset management tool, I would find it very convenient to have a simple reliable facility to have split, merge and copy parts of an IMatch5 DB.

Cheers,

[Ferdinand]

We travel quite a lot and there isn't a real option for us to take our full DB of >130,000 images requiring >600 GB on my laptop.,

I don't think the suggestion is to take all your images with you, rather it is to take just the database.  If you open the database on your laptop without the images then all existing images will show as being offline.  This is not a problem.  What you do is add the new images, which will appear under a different drive node, since IMatch will (correctly) regard them as being on a different drive to the old ones.  Now when you return and copy the new images and the modified database back to your main PC, the old images will appear online again, but the new images will appear offline and so will have to be relocated to their new location on the main PC.

[Note that IMatch identifies a drive not just by its letter, e.g. D:\, but also but its "fingerprint".  So even if your images are in the same drive path on both PCs, e.g. D:\My Photos\ 2014\..... etc, then IMatch will know that these two drives are different from their fingerprints.  Hence the need to relocate.]

[hro]

Mario,

Tks for your comments.

We travel quite a lot and there isn't a real option for us to take our full DB of >130,000 images requiring >600 GB on my laptop. 

Graham,
You only need to take your IMatch db,  not your images.

[Richard]

Graham,

You give examples where you would like a separate database and I agree with many of them but I don't see a need to split them or merge them. Simply start with a fresh database(s) for items that are not related to your photography.

[Graham]

"I don't think the suggestion is to take all your images with you, rather it is to take just the database. . . ." I hadn't realised that I could do this. Excellent suggestion. Thank you.

To further clarify my understanding, I see from Mario's reply and Help that rating and labels etc are auto written to XMP metadata. But categories are not - is this correct? Categories are an internal IMatch DB with links to files in each category. I would need to instigate a manual write of such categories to some convenient metadata if I really wanted to preserve such information in the image metadata.

I plan to change to using keywords for much of what I used categories for previously after reading the helpful discussions on this topic. So my concerns about categories may be unwarranted.

Cheers,

[Mario]

Regular categories (categories not under the special @Keywords top-level category) are stored in your database. They a are very fast and safe in the database.

There is usually no need to somehow 'copy' them into other metadata. Use hierarchical keywords in this case (Keyword Panel). Hierarchical keywords are stored in the metadata associated with your files, and IMatch mirrors keywords automatically in the categories under @Keywords. This gives you the best of both worlds, and fully integrates 'in-file' keywords with the dynamic categories of IMatch.