Is it possible to move a replicant to a different database? For example, I have one database for my credit card statements and a second one for my expenses. If I paid an expense with a credit card, and that is my only receipt, I’d like to put a replicant of the credit card bill in a group in my expenses database. But the only option available on the replicate menu is another group in the same database. Would I have to make a copy instead?
Replicants are database specific and therefore the only possibilities are…
- to copy the document
- to index the same file (stored in the filesystem) to multiple databases
I’ve been moving folders between databases – just by dragging from one, and dropping them in the other.
First question: was that a mistake? Should I have exported the folders to Finder and then imported them into the destination database?
Second question: Now that I’ve done it the (perhaps) wrong way, I have replicants in different databases. I’m looking for some way to:
1 / find all replicants with a missing ‘copy’ in the same database (i.e. all ‘broken’ replicants; and
2 / convert them all to duplicates, at a stroke.
Can anyone help?
Dragging a folder from one database to another affects a MOVE of the folder, unless the Command key is held which affects a COPY.
NOTE: Copying will not carry the Replicants from the original database on a Command-drag. I just wanted to show the two drag styles related to what you were doing.
When you move a folder with Replicants to another database, the Replicants in the original database are deleted - and not Trashed and recoverable but they merely vanish because the parent is no longer available. So there’s really no such thing as a “broken Replicant”.
I see; thank you! Two follow-ups:
1 / But the replicants are still highlighted in red, because they think they’re still replicants. Can I fix that?
2 / I misunderstood how replicants worked; I didn’t realize there was a parent-child relationship. Is there a way to reveal which is the parent, and which the child? In other words, I want to avoid making this mistake again.
- I hope i didn’t misspeak so here is a clarification…
If I have a file in a Group and make a Replicant in the Inbox of the same database, moving the Group to a new database causes the Replicant in the Inbox to vanish and the filename is no longer red.
If I have a file in a Group and make a Replicant in that Group, or a subGroup of the Group, moving the Group to another database retains the Replicant statuses. This is because the files are logically joined and moving together. This also applies if the Replicant is in another Group. Essentially, if a file and its Replicant and part of the move function, they will survive the trip.
I hope that makes it clearer.
- Also, the use of the “parent-child” term was a bit loose. Technically, neither one is the parent or the child. They both have an equal status. They both ARE the file. So you can delete whichever one is unwanted. (Pretty magical to delete something you don’t want and still have the very thing you deleted! )
Note that you can bring up the Info pane for the file and click the “Replicant/Duplicate” button at the bottom to see the locations of Replicants.
Jim is correct that neither is parent or child, but a case can be made that they do not have equal status. If, as Jim mentions, you bring up the Info pane and click on the “Replicant/Duplicate” button, the documents will be listed in the order that they were created. The significance of this hierarchy is apparent when you do a search. A replicated document returned in a search will show the first occurrence of the document, or in the Info pane hierarchy, the top item in the list. If the top replicant is deleted from the database, then the (for a lack of a better term) ‘master’ replicant will be the next item on the hierarchal list, and consequently will now be the document returned in a search.
This info doesn’t change anything about your original question, but for those more curious about replicant behavior, it may be insightful.