AppleScript could be written to open up all your databases and perform finds on them, then perhaps report back the number of results in each table/file, but I think the real question is why are you separating your files like this? There is probably a better way.
<why are you separating your files like this?
It's the way I have always done it. Some are over 1GB. Maybe I could make one big database of all of them, just for searching.
This isn't difficult.
Say you have a directory called "FMPDATABASES".
You could write some simple JDBC (Java) logic that would:
1. Get a list of all FMP12 files in that directory
2. Loop through each FMP file in that list.
3. Do what ever you need to do with each FMP database including any reporting you need to do.
You could even schedule this task to run at specific regular times using either Task Scheduler (Windows), or Cron (Mac).
FMP's JDBC driver makes this type of task straightforward.
I thought of ODBC with UNION query, but anyway you need to open all databases in FM, so without FMServer it may not worth, especially if there need word search in text field (cause slow wild card search in SQL).
It's true that the FMP JDBC driver unnecessarily restricts JDBC to the same physical machine. This same-machine-only restriction is a ridiculous, non-technical, FMI goof that only makes me use FMP less, not more. (Note: FMI -- I'm not nudged into using FMS due to this ridiculous restriction of your JDBC driver.)
But, if all the OP's FMP files are on the same physical machine, the JDBC option is free, fast, and not difficult.
The realistic answer is to create one database to store your data as suggested by Jason. Do this and your job will become much easier.
having multiple databases for the same info doesnt seem reasonable to me. But you could make a master database connect all your tables in the database and then do a query in the master database looping all the tables
Except the OP said he wanted to do this task "Outside of FM" per the posted subject.
Using Java is totally outside of FMP, can connect to any database or number of databases, etc.
That solution may be outside what the OP wants to do, but it meets the objectives. I don't know any other way to do all this task totally OUTSIDE FMP.
A single database is the easy way out assuming that's plausible.
Word of caution, you can crash JDBC with overly large queries. I'm not sure what rules go along with that, just that it happens. I'd warn against doing large single queries, and would instead recommend smaller queries in some sort of order, like:
Get List of Databases
Get List of Tables
Query Each Table, Add results to Result set.
Return Result Set
"Some are over 1GB."
Might the large file sizes be due to embedding image files into your container fields? If so, you might consider external storage.
Well, I don't think you'll ever crash JDBC with large queries ... unless you exceed memory (which is configurable). However, to your point, I completely agree and always use paging as defined in any SELECT statement.
Note that FMP's paging syntax is different than, say, MySQL, but they both do the same thing.
If you have a particular demonstrable use-case that will crash JDBC Java code other than large queries, which you should handle with paging anyway, please update this thread.
rgordon said "The realistic answer is to create one database to store your data as suggested by Jason. Do this and your job will become much easier."
Last night I imported all of my related but different subject databases into one master database for searching. Thanks!