3 ms·
I wouldn't rag on it or Access too much because it serves/d a purpose: app and data design for less technical users who are busy doing a million other things. I
by campfireveteran 7y ago
I wouldn't rag on it or Access too much because it serves/d a purpose: app and data design for less technical users who are busy doing a million other things. I supported several dozen FMP apps at Stanford Student Housing (R&DE) as it was easy for analysts to make something quickly and worked at the scale needed. Later, they used proper databases, reporting, and app-ish tools. FMP ran on a half dozen early Xserves which used goofy, consumer-grade parts inconsistently while looking Apple over-designed.
- EvanAnderson 7y agoI'm not talking-down either one. They're both great tools for their purpose. I've used Access a ton. I guess I'm talking about a cultural difference. It's been my experience that Access devs know when a problem is mismatched for Access (and move to storing data in SQL Server, etc). FileMaker devs seem to press on even when it's clear that the platform isn't capable of supporting their needs. As one anecdote (of several): I support an instance of a FileMaker application w/ several 500MB+ "FMP" files, each of which take _hours_ to "integrity check" when the "FileMaker Server" process crashes unexpectedly. We talked to the dev about putting at least some of the data into an RDBMS (MSSQL, Postgres, etc) and they scoffed at the idea. It simply didn't occur to their mind that the platform might not be a good fit for the purpose.
- usrusr 7y ago“(Almost) the same SQL as the big boy toys" was the most redeeming quality of Access. It somehow managed to be beginner accessible and productive without dumbing down, reinventing the wheel skillset lock-in. Had Microsoft gone for a more custom interface like Filemaker instead of just nicely packaging up more general tools, my entire life might be very different and probably not better, even 15 years after having touched Access for the last time.