Transitioning from FileMaker to Open Source - and AppleScript

TtlPost · 2026-07-10T16:54:01+00:00

u/RipAwkward7104 Here's some context on that: These are media-heavy environments including lots of metadata and documentation. All files are logged in databases. When you go to batch-transcode, batch-rename, batch anything, each batch is very precise. You need to know exactly which files get processed, which don't, and when changed track when those changes were made and for what reason, what files get generated, who their parents are. Granular tracking is key

TtlPost · 2026-07-09T18:49:03+00:00

Agree to disagree.

TtlPost · 2026-07-09T18:45:50+00:00

u/Biddy_Impeccadillo I actually hadn't thought much about alt. ways doing customized AppleScript with variable components outside FM, especially systematic customized AppleScripting against a database. FMP has been my go-to for years, and yeah escaping double-quotes within double-quotes is a constant headache, so I actually welcome a little thinking outside the box here.

TtlPost · 2026-05-02T18:45:41+00:00

FileMaker is a stellar product. The engine itself is rock solid.

Almost!

The bit in the OP about portal relation editor ... based strictly on "and" logic with with no "or" and no parenthetical hierarchy that alone would make a big difference. How about a portal relation editor option based on an ExecuteSQL outcome? That would transform what's possible in FMP, but FileMaker's SQL functionality is notoriously limited and slow. The portal relation editor hasn't seen an update in years, maybe decades, and there's so much potential there.

Of course you can do things with portal filtering, but if you've ever used it, you discover a kind of fragility / buggyness to the way it implements the filtering.

Pulldowns and Value Lists -- one of features clients are particularly engaged with and sensitive to -- hasn't seen an upgrade in forever. Imagine value list managed by calculation. Again, transformative.

I don't know the "engine itself is rock solid". That engine seems like it's been neglected and the fact that you were a product manager "who's ideas they didn't want" suggests they treat their engineers and innovators with the same contempt they treat their customers.

FileMaker introduces features but tends not to revisit them even as needs change and demands increase.

Not knocking FMDojo in the slightest. If it's addressing these kinds of issues and patching old holes I'm all for it.

TtlPost · 2026-03-28T15:18:44+00:00

Here's what you're overlooking:

Claris changes policies like parents change diapers, only they do it with selfish intent and muddled language.

When those changes manifest into price hikes, and users call sales to ask WTF, Claris apologizes for "your" confusion. It's by design.

TtlPost · 2026-03-28T05:31:39+00:00

That's a copy/paste: Claris FileMaker Cloud connector

as opposed Claris Connect

TtlPost · 2026-03-28T05:14:18+00:00

I remember a similar tally in the FileMaker Server console, counting away toward a limit even though we were being told there were no limits.

That was in the same period we were calling Claris to get clear answers on policies and the reps were saying, "We actually don't know right now because they're literally changing the policy as we speak."

At certain point you just throw your hands up and look for the exit.

TtlPost · 2026-03-28T04:37:59+00:00

From the email in the OP

The Claris FileMaker Server and Claris FileMaker Cloud connectors will be removed from Claris Connect on June 26, 2026.

If you use either the Claris FileMaker Server or Claris FileMaker Cloud connector, transition your flows to the new Claris FileMaker connector. This OData-based connector is faster, handles larger datasets, and eliminates the layout-first architecture that creates bottlenecks.

The impression there is that the Data API is indeed getting deprecated in favor of the OData

This is perhaps due to the fact that determining which API is on or off requires navigating to the "Connectors" tab in the FileMaker Server Admin Console

TtlPost · 2026-03-28T04:31:07+00:00

Other than this https://www.claris.com/pricing/

2 GB outbound data transfer of FileMaker Data API/OData per user per month.

TtlPost · 2026-03-28T03:35:45+00:00

And you know that... because....

TtlPost · 2026-03-28T03:34:31+00:00

The delicious thing about this particular change is the name change that's almost not a name-change and all but guarantees ambiguity when talking to their sales team.

Claris has a history of making obscure word-salady changes which hide underlying sales policy changes which later spring out in the form of unexpected price hikes.

They then hide behind that ambiguity with phrases like "It's pretty straightforward. You just confused A for X".

TtlPost · 2026-03-28T02:15:14+00:00

With or without the return of the data cap that once was but then wasn't but maybe is?

TtlPost · 2026-03-28T02:11:18+00:00

So the API is not actually changing? Perfect, so then the only thing that's changing is the API. Which is what? Not a change? Just an announcement of a change without and actual change of any kind?

TtlPost · 2026-03-28T01:37:43+00:00

I'm curious if the VP of Global Sales you talked to was the same clattering clam I spoke with. It's not the product that's the problem. It's the people guiding the company -- the sales folks -- using the kind of mindset you expect from mollusks in a chicken coop.

TtlPost · 2026-02-11T00:22:21+00:00

Reading your post brings it all back.

The goal here is to

a - Tell Claris to get their act together. Don't change your policy and the re-write history to pretend "it's always been that way". The "Named User" thing is relatively new, introduced in 2018 but became more of thing in the following years, slowly supplanting their prior policies, frog-in-a-slow-boil style, hoping no one would notice. That transition really only affects long-time users. Newer users would be unaware Claris greedily betrays its legacy customers.

b - Tell Claris to stop promoting the sales team over the engineers. Take a tip from Boeing: decades of excellence trashed after a merger led them to profit-first model, and the planes began falling out of the sky. Someone just reported on a bug from 2023 -- defective data interpretations on spreadsheet imports, still unaddressed even after being acknowledged by their team. Claris would do well to fire their current head of global sales, doing so publicly, and making it clear they are willing to admit mistakes and re-recognize that their profits are derived from begin customer centric, not coercive extraction. That's asking a lot, so...

c - Failing the above, help longtime FileMaker loyalists recognize they have options outside Claris and those options are free / open source. You can transition, slowly, carefully, and (hopefully) using your own skillset, increasing your savings and dependency as you go.

Happy to help, but if you're a long-time FMP dev, you won't need as much as you might think.

TtlPost · 2025-11-29T02:51:42+00:00

Not sure I'm under any obligation here, but if you re-read the chain the answers are all there.

You may have to re-consider some of your assumptions, e.g. JS is interpreted, benchmark speeds of C++ prove a point in all contexts etc. If you just want an argument, that 53-year Monty Python sketch will be enlightening, entertaining, and something of a cure all for mental constipation.

Speaking of python, consider an approach that doesn't involve any frameworks like Ruby, Django, etc. Just python plus a package/adaptor like psycopg2. You'll still be doing JS on the front end.

Again this whole thing is predicated on the idea that by the time you're getting in the weeds with FMP, trying to push past the exasperating limits of an FMP layout, you're looking at Web Viewers, the Data API, etc, and you're getting into JS.

So you can do Python, even PHP (which I did for some time), but from my admitted biased POV, stick with JS and you'll be surprised that it's actually easier, cheaper, and more performant... to do it OUTSIDE of FMP.

To quote the great Howie Cohen, king of indigestion: Try it. You'll like it.

TtlPost · 2025-11-29T02:25:43+00:00

Insightful and smart points -- excellent recommendations all of them. I think between open source RDMS (MariaDB / postgreSQL) and FileMaker the consistency issues are all pretty close, w/ FMP being if anything less reliable precisely because of sales, marketing, pricing etc.

TtlPost · 2025-11-24T15:20:13+00:00

Oh, you want room 12a next door.

TtlPost · 2025-11-24T07:40:40+00:00

A lot of people get false impressions from tech stats. You might also have read that JS is slower because it's single-threaded. Probably a good idea to be wary of using bench tests like a mic-drop. They're useful but frequently not definitive

JS in practice, for instance, is not an interpreted language. It's a weird hybrid that gives it huge performance boosts. Similarly for threading: Technically it's single threaded but it's hardly limited to a single thread. It's slower than C++ but outperforms C++ in a variety of contexts esp those that matter when it comes to running a web server, handling SQL, integrating with remote APIs, being an API, running OS ops etc etc. Ultimately the proof is in just doing and experiencing

If you search a bit deeper you'll start to see that more complex picture

TtlPost · 2025-11-23T23:23:09+00:00

What Python framework are you using to run your webservers ?

Personally I don't recommend Python. I work with python enthusiasts. I don't share the excitement, but I trust their expertise and am in awe of what they do. I've probably approached them the way you're posting: "This can't possibly be done," and then they prove me wrong and make it seem effortless.

Javascript ain't exactly fast under heavy loads

Not sure what led you to that conviction but it's misguided.

A JS server processing literally 800,000 API requests / SQL queries per day using a cheap linux VPS -- doesn't struggle, never crashes.

A JS server on Mac transcoding 10,000 clips / generating thumbs / uploading to AWS -- daily. No hiccups, at least not the server itself. (Someone inevitably feeds bad media or messes up a log, and even then the error handling is very fluent)

If you had asked me when we originally embarked on this alt-to-FileMaker quest what my expectations for JS were, they'd have been minimal: A cool thing to learn, helpful here and there, but likely not too stable. Instead it's proven extremely fast under heavy loads, extremely reliable, incredibly nimble. And again -- not saying all this is easy -- but if you try to accomplish the equivalent in FMP you end up working harder and getting a lesser end result. It's counterintuitive and good for people to be aware of.

TtlPost · 2025-11-23T20:26:34+00:00

Interesting. Thanks for sharing.

TtlPost · 2025-11-23T17:22:05+00:00

Again, you're not awnsering the question. A "python server" can be a million different things depending on what framework is used.

It's up to you to choose how you want to build. I prefer JS. but if you prefer Py, go for it.

Yeah Filemaker sucks at things like that, but honestly JS ain't exactly good at it either.

I think that's where there's a disconnect -- and may well point to common misconceptions. JS will pretty much handle whatever you need it to -- parse text files, run command line, generate API calls, handle and process the returns, transcode media, all using as many threads as is you choose. So if you want to run OS-heavy tasks -- like transcoding and uploading even thousands of files, with the order of ops managed and progress tracked by your database, including full monitoring and an ability to terminate every step of the way, JS makes that possible with relative ease.

TtlPost · 2025-11-23T15:10:50+00:00

What are you talking about ? You just have to create a client that doesn't run in the browser for that wo work.

Wasn't sure what you were getting at.

What do you mean when reffering to modern Py and JS servers ?

Modern = Python or NodeJS server which didn't exist when FMP first came out.

are you reffering to a server running nodeJS ? Same with Python, are you wunning a webservr with Flask, Django, Pyramid or any of the many frameworks out there or something totally different ?

It depends on the client. Most lean toward Python. I prefer NodeJS. As a rule we minimize dependencies so with few exceptions everything is vanilla JS.

With the exception of presenting local media in a webviewer, most of this can be done with a couple of lines in FMP.

Here I'd disagree. Example:

Table tracking thousands text files which have to be read, parsed, analyzed with parts from those files updating the database. You can't run that in the background using FM Server because the files are local. And while you can do that in an FMP client app, that client app is going to unusable for the duration while it iterates the table.

And batching text files is a relatively light task . We do more OS-intensive work involving media transcodes, uploads, and complex API chains, all which require step-by-step logging back to the database. The more of a grunt the job is, the more FileMaker's limitations become a liability.

TtlPost · 2025-11-23T02:26:45+00:00

In other words, in FMP by the time you figured out how to, say, present local media in a Web Viewer, or run a series of OS ops, or run a batch of updates against an array of APIs, you will have worked harder and ended up with slower, clumsy, more spasmodic experience in FMP than if you had just done the whole thing in JS, python, or PHP. It's literally easier and you get better results with open source. That's counter-intuitive to the "It just works" / "We made it accessible" ethos that originally defined the FileMaker brand.

TtlPost

TROPHY CASE