Possible to "merge" two iMatch5 databases into one?

[Panther]

OK, one more (last?) question before I take the plunge on version 5.

If this will work, I plan to buy two copies of iMatch5 because my wife has a project underway on her PC and I have a related but slightly different project underway on my PC, and we could get the work done more efficiently (in terms of the use of our own time and work stations) if we didn't have to share the same copy of iMatch5 on the same PC while we were doing the bulk of the data/image entry process.

However, that will of course wind up creating two separate databases (with similar but slightly different categories).  Eventually, we will want them to be merged into a single database.  So, the question arises as to whether it will be possible to take my database (which will be the smaller of the two) and somehow merge it (with all its cataloged image files and all its categories and file associations, etc.) into her database and have them function as a single database at that point?

So far, I've been relying primarily on "categories" in iMatch as my main way of organizing, searching and retrieving images, and not trying to embed that information in the files themselves - do I need to figure out a way to put all that category information into the files' metadata in some fashion to make this kind of merger possible/feasible?  Or will iMatch let me just fold in the files and categories from my database into hers?

[Mario]

It is not possible nor intended to merge IMatch databases. At least there is no automatic feature. So much can go wrong, so many things can differ slightly in two databases. The complexity of a merge feature would be enormous - I don't even think about it.

Some general tips:

Read the help on sharing databases.
Read the help on "Traveling with IMatch".

Then:

You can export/import categories using the corresponding features. If both databases have the same files, you can export the databases from one database and import them into the other database. If you store metadata in the files, it will be picked up by IMatch when you add the files. The @Keywords category hierarchy is automatically mirrored in the XMP (and optionally) IPTC data in your files. See the help on @Keywords for more info.
See Category Import and Export in the help for details about how to export and import categories.

There is no feature to write IMatch categories in your files. If you want to keep categories also in your files, use @Keywords. Stay away from schemes like using metadata templates to copy categories into metadata. It's usually not needed, helpful and complicates matters.

If categories are the only thing you need to merge, and you really need two databases instead of sharing one, just make sure both databases index the same  files, and export/import categories as needed.

[Panther]

Thanks for the reply, and the tips and warnings.  I will read up on the help topics you mentioned.

My intention/desire is that the two databases on the two PCs would (while separate) be managing two separate sets of files, not the same files, but that they would use the same set of categories (although without very careful coordination I'm sure the list of categories might diverge over time inadvertently).  Then, once the bulk of the two separate image entry/cataloging efforts had been completed, the desire would be to combine all the files into a single database, without losing the category associations to those files that had been created while the databases were separate.  From then on, the plan would be to run only the single, combined database with all the files from there on out.

I guess the best way to figure out whether this has a prayer of working is just to try it on a couple of small test databases, after absorbing those help topics you mentioned.

Thanks again for all the help and support!

[Mario]

This should be doable with a bit of planning and the category export/import.
Good idea about the test database.

[Panther]

I'm loving iMatch more and more as each test goes by

Turns out it wasn't hard to test this theory, and it seems to be possible with relatively little difficulty (at least if you only have to worry about categories and attributes).  In case anybody has ideas of doing the same thing, I've set forth below the basic steps I followed to successfully merge two small test iMatch 5.2.5 databases:


How to merge (simple) iMatch 5 databases:  DB1 = main database, into which DB2 (secondary database) will be merged, where DB1 has been running on one PC (PC1), and DB2 has been running on a second PC (PC2):

1.   Copy the iMatch DB2 file(s) from PC2 to PC1
2.   Copy the image files being managed by DB2 from PC2 into a separate folder on PC1
3.   Start iMatch5 on PC1, and open DB2 on PC1, doing a "relocate" and "rescan" of the DB2 image files as needed (since their location on the drive will have changed in the move from PC2 to PC1), and confirm that DB2 is operating properly on PC1 before proceeding
4.   Export DB2's categories, with file associations (using Command/Import&Export)
5.   Export DB2's attributes (Select ALL files in DB2, then open Attributes Panel and use the .csv file export function from the configure button on the Attributes panel) (be sure to use full file name option, and choose to export all items when it asks)
6.   Close DB2
7.   Open DB1 on PC1
8.   Use Command/Add folder to add the new folder of DB2 images to the DB1 database
9.   Use Command/Import&Export to import category list from DB2, with file associations
10.   Use Command/Import&Export to import .csv file from DB2 attributes – (tell it first row contains column headers, and that the file name column contains the file names, and select the correct attributes to map from/to). (NOTE - this works if you have the same set of attributes in DB1 as in DB2, so they will map easily from DB2 into existing attribute fields in DB1 - not tested to see what happens if the list of attributes used in the two DBs are not the same).

That's it


This has been tested and works (at least with simple test databases) even if category lists in DB1 and DB2 are slightly different.  I have tested this only for transfer/merging of categories and attributes – not sure what problems or complications may be experienced regarding other things like metadata, scripts or other things I haven't used in iMatch yet.

Be sure to do this only using a backup copy of DB1, in case something goes wrong with the merge.  That way, you should be able to go back to your working copy of DB1 if you have any problems with the merge.

[ubacher]

I have been merging DBs using the procedure outlined by Panther with success.

Simplified: Export Categories with file assignments
                 Ingest the files which are to be merged.
                 Run category import.
                 Do also attributes export/ import if you use attributes. Have not done this.
                 Make sure all metadata write-backs have been done on the db of origin before you transfer the files!
This will not copy flags, pins, dots, bookmarks nor (I think) rejected files.

To start with the second DB import the (previously exported) category tree. This will at least give you a common
category tree to start with.

I work long periods only on a laptop (while traveling). I have tried the recommended method of using pack&go to copy
the main db and work on it on the laptop. That works - but I am too chicken to copy the db back to the desktop upon returning
(using Pack&Go) lest I have made some unintended changes to off-line files.  I thus use the category export/import method.

On my last trip I started using a fresh/new db to see if the problems I encounter on the desktop would vanish.
They did not but the gain in working speed (especially compact/optimize) was significant so that I will continue that way.

Problems: Any changes to settings in IM will not be transferred from laptop to desktop when not using Pack&Go.
What we would need for this is an EXPORT/IMPORT of IM settings. 

[Mario]

This will not copy flags, pins, dots, bookmarks nor (I think) rejected files.

Rejected files are stored as a rating of -1 in the XMP record to they travel.

What we would need for this is an EXPORT/IMPORT of IM settings. 

Just copy the settings database. It stores per machine/user/database settings and can be transfered between computers.