Would be helpful. Must be some complicated reason why it’s not possible.
A replicant is like an alias. It is limited to the current database because DT doesn’t track original files if the source database is closed or the original of an indexed file is moved on disk. It’s possible (Finder does it) and maybe some day it will happen.
@korm is correct on the why you cannot replicate between databases, and is also correct that if the location of an indexed file is changed, DT will loose track of it. I do share some files between databases, and I get along well by indexing those file. I am careful that they have a permanent location in the filesystem so that DT can find them.
So, does this mean all of your files are indexed rather than imported, so that they all files are located outside of any database? This seems the only way to effectively cross-reference files among many specific databases, as I have been trying to achieve. (This is why I love The Brain…it lives and breathes cross-referencing.)
Do I really have to Export every file and folder out from every database I have created and then Index them exclusively?
Does anyone else have a workaround, maybe a script, that accomplishes this?
You don’t need to export and index “every file and folder” unless you plan on using every file and folder in every database you create. If that’s the case, maybe I’d reconsider why I have a lot of databases instead of consolidating them.
“Some kind of workaround” – to accomplish what? I think Greg explained the best approach already.
From a logical point of view, it makes absolutely sense to not go beyond a given database in terms of cross-referencing. As pointed out above, one database has no control over or guaranteed knowledge of what’s happening in another one (I am not a DB expert, but to me that almost sounds like the definition of “one unit of DB”: everything that potentially has to be updated MUST be available at all times so that it can be updated; if you can’t update live, you will end up in “sync hell”). Tying them together would quickly lead to major disasters. What if a cross-referenced item within two DBs is updated independently while the other DB is closed? Or one DB might be shovelled onto another computer and return after a prolonged time.
I choose my DBs to have clean delineations. Depending on what you do that can be easy or hard. For now, all my work fits into one DB, and private matters go into another one. There are a few items that are needed in both, and indeed, these I keep in a special (Finder) folder, that is indexed into both DBs.
The method of indexing the same Finder folder from multiple DBs is effectively introducing an additional “bridging DB” which is always open (i.e. the Finder). And you have to meticulously maintain that folder, otherwise items go missing, and most importantly, their DT metadata is gone. Also, only the file itself (plus internal annotations and file-system metadata) are shared. The different DBs still don’t know about what’s happening in the other DB, e.g. what groups were assigned.
It sounds more like you started out with the wrong design philosophy. Are you saying that only after you put thousands of items in a multitude of DBs, you finally realize that you want to replicate between DBs in a massive fashion? Why did that not come up early on?
Do you have huge amounts of data, or possibly too fine-grained DBs? I hit that issue very early on. First, it looked not like a bad idea to have many DBs. After all, they could be open at the same time, and effectively searched. But I realized that all my work-related stuff needs (at least potentially) be cross-references across the whole spectrum (to me that’s the whole point of a DB-based information system). So I adopted the strategy of using very few DBs. I will only move away from that if I get the impression that performance suffers. So far so good.
Even there is not possible to replicate between databases, others databases appers when selecting folder in defining replicate rule in smart rules, this is confounding to users
I don’t understand what you’re saying here.
- I want to create smart rule
- I am choosing “Search in” : a specific single database
then I set some conditions; - In smart rule I want choose:
Perform the following action …
“Replicate” to …
Expected:
In the menu of possible destination I will see only destinations in current database (the database I choose in “Search in”), because replication to other databases is not supported
What I see:
The same destinations as in Duplicate, choosing destination" Replicate to" outside currrent database is possible, but the rule then doesn’t work
Proposed Solution:
List of folders should dynamically change and be based on context and display only valid destinations
Wow… go figure… as a noobie to DT3, I spent about ½ an hour looking for ‘why’ this wasn’t possible… When I choose ‘replicant’… the destination I want… wasn’t available… I was in denial… “how can this ‘NOT’ be possible?”… I kept thinking to myself…
I even created a replicant, sent it to the INBOX and then tried to move it to the place I wanted it… but it moved the ‘original’ file… I even tried closing DT3 thinking it simply wasn’t ‘seeing’ my newly created database. But after re-opening, my destination ‘still’ wasn’t available…
I finally ‘gave up’ and hit google search, which brought me here…
It ‘makes sense’ that files can’t be across 2 databases… now… but… ‘replicant’… should be re-named ‘local replicant’… or ‘something’ to signify the cross-database limitations… ‘database replicant’ perhaps… it clearly is NOT a universal replicant.
in my mind at least… a ‘replicant’ should be available to put where I like…
1 Like
True story 