Unexpected results merging indexed image files in a Smart Group

This isn’t a bug – after I realized what was going on it made sense – but it caught me off guard. I searched the forum but couldn’t find any mention of this, so I thought other users who work with Smart Groups might want a heads-up: Actions you perform on multiple files in a database group or subgroup may not produce the same results when you perform them on multiple files in a Smart Group – even if those files are also located within a single subgroup.

My genealogy database is almost entirely indexed files, with an indexed Finder folder “Documents” with subfolders for different record types (e.g., Vital Records, City Directories, etc.). Merging two jpgs in an indexed subgroup/folder produces an indexed pdf file, in the same subgroup/folder as the jpgs. So when I merged two jpgs that were in the same indexed subgroup, from within a Smart Group that brings together files throughout the database (tagged with a specific surname), I wasn’t expecting to get an unindexed pdf file that wasn’t in any group at all.

My first clue that something was wrong was that the merged pdf didn’t sort with the jpgs it was made from. The Smart Group is sorted by Location (subgroup/subfolder), so all files for one record type appear together. The jpgs were both in the City Directories group, so I had expected the pdf to appear there too, but it stubbornly stuck to the top of the list. The pdf was not in the City Directories folder in the Finder. Then I realized the merged file didn’t have the “indexed” icon. It wasn’t in the Inbox either. But when I selected the database icon in the navigation sidebar, I found my unindexed file in the database root.

On reflection, I realized that because the Smart Group targets (“Search in”) the database itself, including all groups/subgroups, the only logical place to deposit a merged file is in the database root. DTP4 puts the file into the group you’re working in – in this case, a Smart Group – regardless of what other group(s) the original files were in.

I haven’t tried any other actions that might be affected in the same way, but at least now I know that seemingly anomalous results may stem from working in a Smart Group.

There’s a misconception here: nothing is ever „in“ a smart group. Smart groups are similar to saved searches in Finder: they do not contain anything.

3 Likes

Hmm. Well, so much for that explanation. So, does anyone know why the merges behave differently in the two scenarios? I could understand the rationale if the files selected for merging were in different indexed locations, but these were in the same folder.

So, what happens if you merge two files in a group (ie not a smart group)?

While development would have to comment with more authority, this could be unintended behavior but IMHO smart groups aren’t really intended as working groups but as a place to display matching documents.

In case of smart groups the destination is the search scope of the smart group (since version 4.1.1).

The merged file is created in the same group.

So my initial deduction was correct after all – if the search scope is the database, the destination is the database root. Thanks for the verification. I may have to rethink parts of my workflow.

1 Like