I am working on a FileMaker Pro database which I will want to store in (and open from etc) DEVONthink (3.8.3 on 12.4).
As things stand now - because of limitations of its structure - that FMP database creates and exports a subfile to the same directory in which it ‘finds itself’.
Aware of the need not to “go behind DT’s back” and move files in and out of its own database, do I dun any risks by having my FileMaker file create and store such a file for itself - at the Finder level - once it’s been properly imported into DT when I run it, please?
It will create an orphaned file. This will be detected and imported into the database when doing a Verify & Repair. However, Filemaker is likely to produce another one when it finds that one missing.
If you can’t disable that function in Filemaker, you’d be better off putting the Filemaker file in a Finder folder and indexing that folder into your database.
Just too be clear: the (‘main’) FileMaker file will be inDT. It will create a subsidiary file also inDT.
My concern is that that subsidiary file won’t have been imported properly into DT; but created and saved there (by FileMaker) at the Finder level.
Does that threaten the integrity of the DEVONthink database: my understanding is that you should never mess at the filesystem level with any files which DT manages?
That’s true in case of imported documents, these should only be opened/edited externally but not moved, renamed or deleted via other apps nor should new (auxiliary) files be created inside database packages via other apps or by the user.
However, I wonder what’s the point of adding a FileMaker database to DEVONthink?
It won’t corrupt your database, but again, it will create an orphaned file in the database package DEVONthink knows nothing about. That is not an ideal thing to be happening. This is why I suggest you create a folder, put in the Filemaker file, and index it.
Thanks so much for the clarification, Christian. My understanding was correct, then.
I am so in love with DT that I want to use it for as much as I possibly can
I am considering a compromise: to keep the main FileMaker file in DT, but to have the subsidiary/auxiliary/dependent files it needs to create elsewhere on my filesystem - outside of DT.
IOW keep all the FMP and its dependent file(s) outside DT in their own folder - say in ~/Documents/Data - and index that folder so that DT can instantly and easily keep track of whatever is in that external folder?
With due respect, why are you doing this? The data in FileMaker presumably is in its own structure already anyway. I’m curious what the value-add you for you is?
I can understand putting snapshot exports of reports, csv, etc. into DEVONthink, but the entire database file(s)?
to keep the main FileMaker file in DT , but to have the subsidiary/auxiliary/dependent files it needs to create elsewhere on my filesystem - outside of DT .
If that’s possible to control, yes you could use this approach.
IOW keep all the FMP and its dependent file(s) outside DT in their own folder - say in ~/Documents/Data - and index that folder so that DT can instantly and easily keep track of whatever is in that external folder?
Yes this is feasible and would keep the files together in the Finder.
I hear you. When I switched to DT, I decided that it was so useful and so reliable and so well designed, structured and maintained in every way, that I really would make it my main (almost only) repository for all data files, all such files as I otherwise kept in my ~/Documents hierarchy.
Not least amongst those reasons was categorization. I have a complex and very useful set of folder hierarchies (= Groups), carefully colour-coded, in which I store practically everything according to its content… finance, writing, planning docs, arts etc.
This particular FMP file fits perfectly into that categorization/hierarchy and has its place there - alongside all other docs (Weblocs, PDFs, PDFs etc). I really do like having such things grouped together.
It’s difficult to argue with a person in love. But what is the point of putting a database in a database? What do you hope to achieve? Besides of having everything in a beloved product, that is. Would you consider putting an operating system into DT, too? Kernel extensions? Preference panes? Binary plists? If so, why?
Can DT find content inside a FrameMaker database? If not, storing it inside DT has no benefit at all.
group files for like subjects (art, finance, sport, history, planning, work) together
have access to (data) files in logically-categorized hierarchies
DT excels that that. I see little sense of having to look in half a dozen places for, say, all the information I have on, say, drama… PDFs of scripts, texts, images, URLs, reviews and so on. I’d be sure to miss something; or frustrate myself by being unable to find it.
DT allows me to put all the material I have in a carefully planned set of folder hierarchies. That includes database files.
Not really; I use it meaningfully and with extreme clarity to group data files of all kinds, instead of having multiple directories and subdirectories scattered at random in ~/ and/or ~/Documents.
(Almost) everything for any one ‘subject’ is in one very accessible and easy to index, find and use place.
No, I wouldn’t do that. But if I have a set of files - including a FMP database - whose category is Shakespeare (texts of his works, scholarly articles, links toJSTOR, images of contemporaries, PDFs of theatre plans etc…), I know just where to find them
I suppose this just shows how flexible and robust DT is.
AFAIK, the file format of Filemaker Pro has always been proprietary. For example, Apple/Claris has never made a FMP database searchable by Spotlight. This is quite different than the DEVONthink model.
One possible integration of FMP and DTP would be to use an FMP database as a sort of “front end” to a DTP database, where individual items such as documents, JPGs, etc stored in DTP are linked to FMP buttons or other programmable interface tools. An example could be a music album such as the Miles Davis album “Kind of Blue” having many associated documents in a DTP database (which handles documents extremely well) with a FMP database containing the interface including buttons, sliders etc to call on the DTP links, as well its known capabilities for sorting, reporting, etc.
Thanks, @3865; it’s just a dependent file which FMP creates that I’m worried about. But I’ve actually solved it in another way - by putting the main file in DT (in which I store as many of my files as I can) and its dependent inside ~/Documents/Data etc.
The discussion above is largely about what FMP might do to DT. I wonder what DT might do to the FMP database. My understanding is that FMP databases are notoriously at risk of corruption when interfered with by other programs, to the point that you’re not even supposed to allow Time Machine to backup the folder where active Filemaker databases are kept. Since I too use FMP and DT, I would appreciate your and others’ thoughts on this aspect.
Relevant here I think is the idea of “absence of evidence is not evidence of absence”, e.g. as I’m not at all convinced there is any real valid purpose to put a FileMaker Pro database inside of a DEVONthink database no point to experiment. Surely FileMakerPro would then mess with files inside of DEVONthink bypassing DEVONthink, and if looking at files from DEVONthink the files would be messed with bypassing FileMaker Pro. I just would not do and leave well enough alone.
All backup software will work better when the files being backed up are not “open” and in use, including DEVONthink. I run my TimeMachine backups all the time, but schedule backups by Chronosync and Carbon Capture to run at night when sofware not running.
