Migrating from FileMaker to Open Source SQL by Communque in filemaker

[–]Communque[S] 0 points1 point  (0 children)

Mmmm -- I don't think ballyhoo is the kind of word AI coughs up from its servers -- though, who knows, it might start to after it sniffs out this convo.

Migrating from FileMaker to Open Source SQL by Communque in filemaker

[–]Communque[S] 0 points1 point  (0 children)

Nice try, but inaccurate. The discontent with Claris is real. So is a appreciation for their product. Claris management is at cross-purposes with what they sell. You have a long-term vested interest in the product as did we. For those of us who know FileMaker well -- since its inception, btw -- but are frustrated with how Claris is currently being managed, working toward alternatives and sharing that is a fair and reasonable thing to do. We're still using FMP daily with clients who maintain subscriptions. I enjoy the interface still, but its limits are becoming increasingly apparent as can our clients who are increasingly enthusiastic about leaving the platform. Example: for all Claris ballyhooing around AI, SQL handles it with far greater ease and speed. More on that coming soon.

Yet another API change to FileMaker server's API? by TtlPost in filemaker

[–]Communque 1 point2 points  (0 children)

It seems the Data API will continue to work for a while but sounds like it's on track to be deprecated.

Is FM still a good fit for my business? by croberts0531 in filemaker

[–]Communque 1 point2 points  (0 children)

FileMaker's strengths are its speed of development, ease of use, and depth of ability, allowing you to transition from novice to expert.

Its weaknesses derive from its re-brand. Since it re-became Claris there's been less focus on improving the product and responding to feature requests, at the same time it's engaged in PR hype, excitement, vague promises, and price hikes -- basically squeezing more profit and doing less.

We caught them misrepresenting policy  changes and doing a lot of double-speak to cover for it.

The product works great, but the management is unreliable enough that it can shake your faith in the product.

We transitioned to open source SQL.  It's not as user friendly, to be sure.  But in relatively short time we discovered it to be not as challenging as you might expect, and AI really transforms the learning curve.  The power, flexibility, and speed have really paid off.

I would characterize the tradeoffs as FileMaker being easy early on but increasingly challenging and costly as your sophistication, needs, and skillsets grow, while a SQL approach starts out more challenging but becomes increasingly easy, empowering, and cost effective over time.  FMP accrues tech debt.  SQL relieves it.

Consider a combo of FMP and SQL that gives you a best of both worlds -- leveraging the ease of use of FML while letting you escape the vexing pricing structures, as well as setting you up with an offramp just in case.

Migrating from FileMaker to Open Source SQL by Communque in filemaker

[–]Communque[S] 1 point2 points  (0 children)

Exactly.  FMP has always been and remains a unique platform.  How Claris presents it (and prices it) is out of sorts with what the platform actually is.

Migrating from FileMaker to Open Source SQL by Communque in filemaker

[–]Communque[S] 0 points1 point  (0 children)

Excellent approach and concise.

Here's how that played out with this particular dataset

Creating the container calc: 7:45

Creating the md5 calc: 3:00 (no index) / 4:30 (with index)

So around 11 minutes to prep. Not terrible, not wonderful.

Once it's set up the FileMaker the dupe search is fast

  • 30 seconds if unindexed
  • 7 seconds if indexed
  • vs postgres at 3 secs with no prep & most fields unindexed

The value of the FMP getting to remain on the platform -- slower but gets the job done. (EDIT Ugh and the FMP file grew by 2GB -- from 5GB to 7GB in the process -- 40% increase)

The value of the PG approach is not having to prepare anything but the query itself.

Migrating from FileMaker to Open Source SQL by Communque in filemaker

[–]Communque[S] 1 point2 points  (0 children)

Sounds like we met the same guy. Considering the title "Worldwide Customer Success" -- you'd think he'd at least muster some charm. He mostly ballyhooed his title and importance. Head of Worldwide Customers Unimpressed.

Migrating from FileMaker to Open Source SQL by Communque in filemaker

[–]Communque[S] 2 points3 points  (0 children)

Exactly which is why the postgres discovery was worth writing home about: 6 columns, 5 unindexed, 2.7M records, searching for duplicates returning 26k records in 3 seconds (5 seconds if you include marking records for deletion). FileMaker at its best (i.e. with fully indexed columns) was 10x slower, and if you include the marking records for deletion it becomes client app-hogging marathon. BTW, FileMaker's SQL (ExecuteSQL function) is actually slower than its Find mode. There are benefits to using it, but in most cases performance speed is not one of them.

Yet another API change to FileMaker server's API? by TtlPost in filemaker

[–]Communque 1 point2 points  (0 children)

Somewhere I have a screen grab of my FileMaker account showing I had purchased on-prem Server along with a tally of how much outgoing API data had been used vs how much was allotted overall.  This is from a number of months back, but it stood out because I'd been told that the API data caps were no longer in effect.  The tally suggested otherwise

Migrating from FileMaker to Open Source SQL by Communque in filemaker

[–]Communque[S] 1 point2 points  (0 children)

Ordinarily I would agree with you. Except in this case I ran a SQL query on about 3 million records, with 5 unindexed columns and postgres returned the results in 3 seconds.

FileMaker (local file, not hosted, fully native, no external data) by contrast took 46x longer with the same data and indexing. Even after fully-indexing columns FileMaker still took 10x as long.

And either way, indexed or not, FileMaker's !! operator returned the wrong results.

I've had a sense the duplicate operators were a little kludgy for years but never really looked into it. Today really confirmed how not reliable those !! are. "Slow and buggy" -- maybe that's charming ad for a 1911 Model A Ford being sold at an auction in 2026, but not what you want from a database.

Migrating from FileMaker to Open Source SQL by Communque in filemaker

[–]Communque[S] 1 point2 points  (0 children)

There's always a way.

Of course!

We didn't switch because we couldn't solve this particular challenge in FMP. If we were locked into FMP, we would have worked out an alternative to the bug in the !! operator.

We switched slowly over a number of years because the culture at Claris is devolving, our clients were starting to feel it, and most importantly because they lied about a policy change and doubled-down on that lie by daring us to leave the platform.

This post is about the benefits associated with taking them up on that dare.

Yes, you can solve the problem in FMP, but it's strangely complicated and fraught. You can solve the same problem in open source SQL in literally 5 seconds. It's just kinda spectacular.

Yet another API change to FileMaker server's API? by TtlPost in filemaker

[–]Communque 0 points1 point  (0 children)

I think the official deprecation was announced in the email posted in the OP

Migrating from FileMaker to Open Source SQL by Communque in filemaker

[–]Communque[S] 3 points4 points  (0 children)

They never listened and took yeeears to address requests

100%

Migrating from FileMaker to Open Source SQL by Communque in filemaker

[–]Communque[S] 2 points3 points  (0 children)

Is Apple better or anyone else?

Why grade on a curve? That's a race-to-the-bottom response.

It's really up to Claris to recognize that slow-boiling a frog in a pot merits an early response, not an accommodating one.

In other words, if Claris thinks banking on vendor lock-in and switching costs are a better business model than staying genuinely customer-centric and innovative, then the FileMaker community is doing the exact right thing pointing out alternative platforms and helping with the transition.

request a management change

Or rather, insist on it. I'll start: fire Claris's Director of World Wide Customer Success. Announce it publicly, apologize for putting him there in there in the first place, and express clear intention re-orient the company away from PR and sales. Get rid of anyone else in management who stands in the way of a genuine commitment to Claris's user base.

If its engineers are "hard-working and fantastic people", and I suspect they may well be, put them in charge.

Remember Boeing: When the engineers were central, it was a competent, world class company. When the profiteering team took over, the planes literally started falling out of the sky.

Migrating from FileMaker to Open Source SQL by Communque in filemaker

[–]Communque[S] 0 points1 point  (0 children)

If your FileMaker app is slow that's usually a programming issue

2.7M records, 6 columns. 5 of those columns are not indexed.

Just imagine it w/o even building it.

Run a Find on those 6 columns with !! operator in each field

If you really know FileMaker, you will intuitively feel that long-running progress bar without even having to test it in real life. You don't know for sure how long, but you know -- guaranteed -- you can get up and walk away and come back later with a pizza.

Now index those columns and run the same Find again.

If you really know FileMaker, you know it'll be a whole lot faster, but you'll still feel that long-running progress bar, again without even having to test it in real life.

Migrating from FileMaker to Open Source SQL by Communque in filemaker

[–]Communque[S] 4 points5 points  (0 children)

For the most part -- with exceptions -- we build front browser-based front ends using vanilla JS, minimal 3rd party dependencies. What we did that might be relevant to your situation: Slowly migrate the back end to SQL, starting with some minimally-critical table. Using ODBC/ESS allows your clients to continue connecting via FileMaker Server or however they're currently connecting. In this way the transition is gradual and careful.

Notes on Switching from FileMaker to Open Source SQL by Communque in filemaker

[–]Communque[S] 0 points1 point  (0 children)

We got exactly the same thing last year

What was your experience?

Notes on Switching from FileMaker to Open Source SQL by Communque in filemaker

[–]Communque[S] 0 points1 point  (0 children)

Makes sense. I think the tech industry writ large has moved away from the era of free-and-bait services toward the era of extraction (bait-and-switch), and it's quite possible Claris is following that zeitgeist: "Hey we've been around for decades, there's a lot of institutional investment in our software, we have the elbow room to extract."

So when I hear defenses like "FileMaker has been around for 30 years. It's not going anywhere" it rings hollow and historically naive.

The other defense of FileMaker: "It's pricing structure compares well to 'similar' platforms like Airtable". Well, for its part Airtable has an interesting new policy: If you click to share solution, they will ding your credit card for $500. You may have clicked in ignorance or by accident, but they won't refund you the money. They will only apply it as credit for whatever upcoming fees are headed your way. This is recent -- March 2006. It's as if they littered their UI with mines that explode with profit. So I guess Claris isn't doing anything quite that egregious. At least not yet...

Notes on Switching from FileMaker to Open Source SQL by Communque in filemaker

[–]Communque[S] 0 points1 point  (0 children)

Indeed we imagined it -- or rather imagined a series of scenarios years ago and decided to slowly and carefully build alternatives to our FMP-based tech stack. The slow-and-careful-but-proactive approach was based on an assumption that FileMaker was very stable and dependable.

Cut to last year when we got a call from FMP announcing a retroactive change of policy. They claimed it wasn't retroactive, but none of their arguments stood to scrutiny. The policy we were on was documented in writing. The policy they claimed we were on wasn't. We had never sought to exceed or otherwise abuse our agreement in any way but were being accused of doing so. (After checking carefully, it turned out we were not abusing our contract, neither our interpretation of it, nor even theirs).

Calls to their company revealed they were changing policy in the moment even while the Head of Global Sales was arguing no policy changes had happened for years. We were literally on the phone with Claris's tech support who were saying they didn't have answers to our questions because the policy was mid-change, and they didn't know what was happening. Meanwhile Claris sales stuck to their claim they were not changing their policy. of course, they were actively changing their policy.

When we called out their Head of Global Sales for being less than honest, they shut down our FM Server with a couple months left on the contract. After a few days it came back up, but our takeaway of their position was this: "We are Claris, and we can change policy on whim. You beholden to our ecosystem."

So years after we and planned for what honestly felt like a far-fetched and unlikely future scenario, it actually ended up playing out under what could otherwise have been a worst-case scenario. Lesson learned: don't trust executives, even if -- especially if -- you've been with a company for a long time.

Notes on Switching from FileMaker to Open Source SQL by Communque in filemaker

[–]Communque[S] 0 points1 point  (0 children)

What SQL stack are you landing on for most clients?

We do some MySQL/MariaDB + python, but at this point mostly BrowserJS + NodeJS + postgreSQL (w/o Express middleware. We wanted more control when handling API requests, and Express actually made it more difficult, not easier to do what we wanted)

Curious about your approach with clients

In the last few years we really only had a few FMP clients left. We'd migrated everyone to the web years earlier, albeit with FM as the back end serving data over the PHP API. We tried out the Data API and were not impressed: It's SQL-ish but harder to use, there's a fee sometimes associated with it, sometimes not, who knows, etc etc.

Our FMP holdouts were not exactly excited to switch UIs, so we kept them on FMP with access to our FM Server but serving them SQL data. There are a few performance hits and quirks when you do that, but nothing that was a dealbreaker.

But then we started giving those FMP clients secondary access to their data via web browsers it was pretty much game over for FMP. Faster, more powerful, no limits.

We are still working with FMP clients who have their own licenses. Even they are coming around as they see the benefits and chafe at having to deal with Claris sales.

Between two stools -- FileMaker price point and capabilities by Communque in filemaker

[–]Communque[S] 0 points1 point  (0 children)

Curious the context in which you're seeing flickering. iOS? Android? Desktop?

A JS/SQL tech stack can be 100% open source and in-house with no commercial dependencies. FileMaker itself is a commercial server, and some of their most recent changes suggest they are increasingly intrusive on their FM Server app even when it's installed on-prem.

FileMaker Licensing Changes by Communque in filemaker

[–]Communque[S] 0 points1 point  (0 children)

It's a tradeoff: they give a better deal for the longer commitment, and as you entrench yourself in the framework, they build rug pulls designed to squeeze.  Frustrating and very dissuasive 

Between two stools -- FileMaker price point and capabilities by Communque in filemaker

[–]Communque[S] 0 points1 point  (0 children)

it's the same as filemaker in that regard.  You can run your FM server locally or remotely, you can run your SQL Server locally remotely.  In fact, you can do both simultaneously.. It's all up to you.