MacInTouch Amazon link...

FileMaker/databases

Channels
Products
This is a followup to my earlier post and to the interesting comments on it. FM Pro Advanced 17 runs well; a few records (4 of 150,000) needed to be fixed in my major solution. Last night, I installed FM Server 17. Installation Is simpler and proceeded without problems. I have not yet uploaded files.

One very positive comment: help and documentation in FM Pro Advanced 17 itself, as well as separate literature both for FM Pro Advanced 17 and for FM Server 17, is now very extensive and deep. A huge improvement! Almost overwhelming. There is a separate manual for JSON for those who may need some guidance when that is needed.

In the past, help and documentation both for FM Pro and Pro Advanced has been both very complete and helpful, but very little was available for FM Server, really only an afterthought for the application.

Earlier editions of the "Missing Manual" for FM were also very helpful. The most recent edition (for FM 14) is miserable in comparison to the manuals on other subjects. Coverage for FM server is superficial.

There is, and has been for several versions of FM, an alternative to "storing by reference" for container images, as suggested in comments by Dennis Chretian, Trilo and Dave B. Container data can be stored in a properly-located [subfolder of the database folder].

There is very detailed information in these documents:

FileMaker Server 17: Uploading database files using FileMaker Pro Advanced
and
FileMaker Server 17: Uploading database files manually

The second document indicates exactly where container data is to be stored.

I had been aware of this but had never tried to use it, nor did FM tech support in our several conversations ever suggest it. It appears to be very simple and straightforward. I look forward to trying. I will appreciate comments.
 
Last edited by a moderator:


EFB

One aspect of FileMaker runtime seems to be 32-bit versus 64-bit, with regard to the runtimes for a Fedex shipping program called NRG.com. We use El Capitan.

We are Mac Pro 4.1 32-bit and reluctant to use a non-approved way to move from 4.1 to 5.1 Mac Pro 64-bit designation to allow Sierra. I do not particularly want or need Sierra at this point, but future Adobe and other updates to software may force the issue eventually.

Cannot afford to update the Mac Pro to a 2012 version at this time.

I have 9 disks and 100,000 photos and 48 GB RAM, and it works quite well. Overall storage for the boot drive is 1.4TB. Solid state drives for all the re-writing and re-saving we do to maintain the web site, along with their unaffordable and therefore limited storage for cache, is also a no-no.

Caching within the 48 GB is wonderful and a big deal for us, with a lot of small and large programs open for web site creation and up-dating.
 
Last edited by a moderator:


There is, and has been for several versions of FM, an alternative to "storing by reference" for container images, as suggested in comments by Dennis Chretian, Trilo and Dave B. Container data can be stored in a properly-located [subfolder of the database folder].
The second document indicates exactly where container data is to be stored.
Yes, this is how I understood it to be and it's very restrictive. The last time I tried was about a year ago and it was annoying we couldn't just leave files where we wanted them.

To use FMP Container fields with FMP Server the files must be placed into the folder structure on the server as I suggested before. This is not a good solution for people who need to do more with their images than just store them in FMP. It's easy to end up with multiple copies of images strewn across multiple locations, which is certainly not what we want - not to mention a waste of space.

I stand by the statement that the deprecation/removal of 'Store only a reference' is a significant negative - at least for us.
 


Can anyone tell me exactly why Apple dropped the database from AppleWorks when they made the change to Pages, Numbers, etc.? It was (and still is, running it on Snow Leopard Server) such a simple program to learn and use, and I could sort and print my database in any configuration. I know FileMaker attempted to enter the market with Bento, but they killed it shortly thereafter. But still... why isn't there a graphical database program "for the rest of us"?
 



I agree that many users start with FileMaker's templates and muddle their way through. Professional FileMaker developers start with their own scratch-built templates.
Templates and very small customers are Apple's target with FileMaker (straight from Apple itself). The third-party / Pro market is an expansion on that. It is a great ecosystem in itself.
in my opinion the separation model is not automatically a "best practice." My clients are small - I can easily shut down their servers at night to work on the databases.
If you never think you are going to leave the FM ecosystem, I agree.

The separation model is a best practice, though, if there is a reasonable expectation that you might need to change platforms at some point. And that's where many devs are right now.
 


Some people have a belief that searches in general will magically be faster if they separate their files; this is not at all so.
I always wanted to try data separation but never quite managed it. In my case, it was so I could make changes to the GUI without having to take the whole database down. As it was, I could only tinker with the database in the wee hours of the night when the clients were all sleeping peacefully.
 


... The separation model is a best practice, though, if there is a reasonable expectation that you might need to change platforms at some point. And that's where many devs are right now.
I'm missing how the separation model makes migrating to a different platform easier. When migrating, the programming isn't going to directly transfer, just the data. FileMaker's exports are very flexible.
 



Also a long time user (V2 actually) and a huge fan. I have developed some databases that hugely reduce processing and production times for moderately-sized jobs (such as massaging SurveyMonkey data and ultimately producing individualised awards). I did once produce a book with embedded maps that was a doddle to update annually. No one I knew would have thought of using a database for this, but FMP was perfect - that was in V2.1.

Unfortunately, FM's frequent upgrade schedule combined with quite high upgrade pricing in Australia has meant that for my limited use upgrading is not an economical proposition. I'm still running V13 on a Mac. At my University, V15 is available via Citrix, and it's OK, but I prefer the local instance.

Still think it's a great product - pity it's so expensive if you don't update regularly and have to buy a new copy. Concerned that the day will soon come when I won't be able to run my older version (a la Final Cut X and High Sierra) under the latest macOS.
 


I'm frustrated, though, with FileMaker's inability to import SQL dumps. (Apparently they differ enough that FileMaker didn't want to deal with that.)
Yea, importing can be a problem. I've had to make Excel spreadsheets to muck data to get it to import.

Back in 1997 & 2004 I wrote an AppleScript to fix FileMaker's export to get rid of the vertical tabs they insisted on using.
 



I've been using Filemaker Pro 10 for some years, having migrating from AppleWorks. I have several important databases with quite complex automation using the internal scripting, AppleScript and QuicKeys: I don't use online publishing. I'm still on Mavericks. So if I upgrade my system, or when I buy a new computer, I will be forced to buy the Advanced version which has a lot of facilities I don't want and don't understand. It's somewhat over £500. There is no other database program which will do what I want, and I certainly don't want to have to migrate and recreate all the programming all over again.
 


I'm missing how the separation model makes migrating to a different platform easier. When migrating, the programming isn't going to directly transfer, just the data. FileMaker's exports are very flexible.
Databases are first and foremost about the data.

There are any number of GUI tool kits out there, some of which will do some things better than others. While some businesses have come up with ways to transform someone else's GUI work or slowly move from one platform to another (I can see this with LiveCode's FM support, for example), at the end of the day, the data is the business.

Getting into specialty features is where you have to decide what is worth it or not and if your solution is about the data, then everything else is a specialty feature, including the GUI.

For example, in our Valentina DB system (a special kind of database format), you can work with data stored there much like any relational database, and use bog standard SQL. That makes it very easy to, say, bring over an SQLite database with little trouble. But there are features which allow massive speed improvements and simpler forms of queries. If you elect to use them, then moving away from Valentina DB later would mean having to convert those back to 'standards.' We get a lot more users of Valentina DB from devs writing custom financial and medical applications because speed matters more to them in interacting with data, making it a worthwhile investment. The speed / performance of the GUI is secondary to them. So we get app writers coming from all different platform types, .net, Objective-C, Xojo, LiveCode, etc.

Filemaker has always been a great solution that scales up pretty well -- until it doesn't. When your client's data was small, and then grows and grows, and the numbers of seats and types of analytic needs grow more complex, there's still a lot you can do to accommodate that growth - but then that becomes harder and harder to optimize things without a radical (and hugely expensive) change.
 


But still... why isn't there a graphical database program "for the rest of us"?
You could have a look at Ninox in the Mac App Store. I've never tried it so don't know it. I used to use FMP back in the day but don't have a real (beyond fun) need for a DB now that I'm retired. On second thought, maybe I should treat myself and have some fun!
 




Databases are first and foremost about the data.

There are any number of GUI tool kits out there, some of which will do some things better than others. While some businesses have come up with ways to transform someone else's GUI work or slowly move from one platform to another (I can see this with LiveCode's FM support, for example), at the end of the day, the data is the business.

Getting into specialty features is where you have to decide what is worth it or not and if your solution is about the data, then everything else is a specialty feature, including the GUI.

For example, in our Valentina DB system (a special kind of database format), you can work with data stored there much like any relational database, and use bog standard SQL. That makes it very easy to, say, bring over an SQLite database with little trouble. But there are features which allow massive speed improvements and simpler forms of queries. If you elect to use them, then moving away from Valentina DB later would mean having to convert those back to 'standards.' We get a lot more users of Valentina DB from devs writing custom financial and medical applications because speed matters more to them in interacting with data, making it a worthwhile investment. The speed / performance of the GUI is secondary to them. So we get app writers coming from all different platform types, .net, Objective-C, Xojo, LiveCode, etc.


Filemaker has always been a great solution that scales up pretty well -- until it doesn't. When your client's data was small, and then grows and grows, and the numbers of seats and types of analytic needs grow more complex, there's still a lot you can do to accommodate that growth - but then that becomes harder and harder to optimize things without a radical (and hugely expensive) change.
I'm still not understanding why having the GUI and data in separate files vs. having them in a single file eases migration to a different database platform.
 




Has anyone tried Panorama Sheets? I used it for several years in the past and found it served my needs well. It was $40.
 



I used Helix back in the early '90s. The concept of graphically driven development worked well enough for relatively simple databases, but was inadequate for the more complex databases I was developing. I remember having trouble laying everything out and joining blocks together on the very crowded Mac SE display. It was also too slow for both development and production.

By the mid '90s I discovered FileMaker and have stuck with it since.
 


Count me in as a huge Filemaker fan. We are a fairly small firm with offices on both coasts. Users connect to their local FM server on a gigabit LAN for speed, but the servers are kept in sync with Linearblue "Syncdek", which also gives us redundancy and data recovery options. Currently we are running FMS 13 with V15 clients. We will upgrade at some point, but the Syncdek integration makes it a little more costly and difficult to upgrade.

I'm not a DBM, but I have little trouble creating and editing layouts and writing scripts, which include direct access to AppleScript (and hence to shell scripts, Python, and a world of others). Integration into the Mac ecosystem is stellar.

Sadly, that "ecosystem" seems to be diminishing quickly. Apple does not want to be in the server market, apparently, and AppleScript may be going that way as well.
 


I reviewed Omnis in Vol. 1, No. 2, but you did a Helix update in Vol. 1, No. 7... :-)
My god—I forgot that I did that. ("...we cannot recommend Helix on floppy-based systems," indeed.)

Turns out that Omnis is still around too, as is 4D. I guess once you've got your data in something and it works, you stick with it...

MacWEEK had a bunch of Helix databases—for everything from news and product tracking to production—when I went there in 1990 to run the reviews department, but I moved the product stuff quickly to FileMaker, and was much happier about it all.
 


I'm still not understanding why having the GUI and data in separate files vs. having them in a single file eases migration to a different database platform.
FWIW, when I try exporting an FMP11 database, it won't let me export the contents of containers (regardless of whether they were added by reference or not). It appears that the only way to export containers is one field at a time, which requires a script if you need to do it for an entire database.

Knowing this, I agree with you - it seems equally awkward either way. If there would be a way to export image references (perhaps as URLs) with the text content of a database, that would be great, but that doesn't seem to be an option.

Keeping the container data separate means the database files don't bloat up with all the container content, but I don't think it has any impact whatsoever on your ability to export the contained object data to another platform.
 


But still... why isn't there a graphical database program "for the rest of us"?
I was all ready to move to Bento... but then Filemaker discontinued it. I decided to freeze my Filemaker Pro at v13. I don't actually use it for much, and I've migrated critical data to spreadsheets, of all things. Maybe someday I'll get another database program. I've tried things like Panorama and Helix (long, long ago) – but nothing has stuck. I'm interested in any slick, simple database applications this community discovers and recommends. Or maybe I'm just getting too old for this stuff.

(In my failed attempt to locate early printed MacInTouch issues, I posted This Post, so I've been doing this Mac thing for a while.)
 


... Keeping the container data separate means the database files don't bloat up with all the container content, but I don't think it has any impact whatsoever on your ability to export the contained object data to another platform.
Containers causing file bloating is a separate issue from the Separation Model. It's an issue regardless of whether the containers are in a single database (data and programming together) or in a data-only database.
 




I didn't know it was still around! I made a small attempt to migrate some important old HyperCard stacks to LiveCode, but it didn't go very well.
All of the articles in MacWEEK were contained in a series of HyperCard stacks, generated by my dear, departed friend, David Morgenstern. He converted them to SuperCard as well, but I lost his discs over the years. It was quite a labor of love for him.
 


When HyperCard was terminated, I gravitated to SuperCard, which has continued to be supported and upgraded throughout Mac OS upgrades
I've never used Hypercard, but I know many people loved it. I guess it just passed me by while I was doing other things. Supercard (at least from its web site) has a very old, 1990's aqua look to it. If the final apps look like that, they would be, um, aesthetically challenged.

Their store is currently down and there's no pricing available. The demo video link is broken and the trial version is not the latest (but they are saying it will be available soon). None of that fills me with confidence but the optimist in me hopes it's just getting ready for a bold new version.

I guess my biggest concern about starting in any new development environment is its longevity. I'm afraid I've become a bit cynical over the years and I have this feeling that any application I adopt gets discontinued shortly thereafter. Apple themselves are the worst offenders...
 


Tap Forms, $50, is a relational database with no scripting language and no support for AppleScript or Automator. On the plus side, it is a native Cocoa app.

https://www.tapforms.com

Ninox, $35 for up to 5 Macs, mentioned above by John M, does have a scripting language. I infer from their website that their main business is a $100/user/year cloud service with web interface.

https://ninoxdb.de/en/

(I have no experience with either Tap Forms or Ninox, just mentioning them as possibilities.)
 


Can anyone tell me exactly why Apple dropped the database from AppleWorks when they made the change to Pages, Numbers, etc.? [...] But still... why isn't there a graphical database program "for the rest of us"?
Is there any relation between AppleWorks and Pages & Numbers? I thought they were clean sheet designs.

I think that these days the vast majority of simple databases are just done in spreadsheets, especially since Excel added auto filters. In fact, it wouldn't surprise me if the number of Excel sheets with no formulas (i.e. just tabular data) is higher than those with formulas.

Case in point: previously someone on MacInTouch asked about an application for maintaining a home inventory. Mine is in a spreadsheet. With a pivot table for spice.

(By the way, does anyone remember the first "database" for Macintosh: Microsoft File?)
 


Symphytum is a really, really simple database.

In fact, calling it a database is optimistic. What Symphytum does is make the creation of attractive entry forms very easy. Data can be entered through forms or directly in a table.

All or part of the data can be exported (.csv) and imported for analysis into a spreadsheet. It is possible to link images into a Symphytum "data collection." Images are stored in a separate folder and when data is exported through .csv, the only mode offered, the file name is exported, but not a link to the image.
The Symphytum Project
Symphytum hides the complexity of a database engine behind an easy and intuitive user interface. The underlying database is provided by the SQLite database management system, which is the leading embedded database solution, used in many mobile apps and modern computer programs, like web browsers, media players and email clients.

QLite is tiny, efficient and very fast. It can handle huge amount of data while being highly resistant to data corruption.

Symphytum may use SQLite, but the .syb files it creates do not open in "DB Browser for SQLite.
Symphytum has obvious similarities to Apple's deceased and unlamented Bento personal database. Symphytum is not locked down as Bento was, and if considered as a way to store and review data using an attractive and adaptable entry form, you may find it of use. It is free.
 


In the 90's I was the Science Dept. Chairman at a medium sized High School (2000 students) for a Science dept. of 11 people. Each year we had the 2 month process of deciding what to order for our materials & supplies needs. Everyone would write out by hand what would help their class and I would collate everyone's wish list by hand. Then I would word process a printed document that would be sent out to the various vendors for them to bid on.

After doing this for a few years, I created an AppleWorks Database and would collate everyone's wish list using it, much better! Later when Apple/Claris released a version for the PC, and the other folks in the dept now had PC's in the classrooms, I put the database on everyone's PC, gave everyone a floppy disk on which to submit their final product to me and then I could just import and combine everyone's wishlist at a press of a key! Life was good!

Then the school district would not relicense AW for the PC's and I moved to another school about the time AW went away. So a great tool was lost.
 



Anyone out there still using Omnis? Omnis 3 was a very capable Mac OS product back in the day and has since morphed into Omnis Studio. Pretty darn hard to discern how much it now costs to deploy, though. I hate it when that kind of info is hidden from a company/product website. Fully cross platform, though.
 


I’ve used Helix (now Helix RADE v7) for decades and still do. It’s actively maintained and updated (albeit slowly). I run several Client/Server systems that have never failed me. It’s relational and pretty easy to program. They’ve maintained the original iconic programming environment, but it does have scripting as well. (I’ve never used that feature.)
 


I supported a foundation that managed the works of a prolific, somewhat-recently-deceased artist. When I came on board in the late '90s, the database was in Helix and worked well: they had a server, and the 5 or 6 people working there could have access to the data on their own machines. When it was time to migrate to OS X, we kept the server on a blue G3, and everyone had to log into it via Classic.

The Helix upgrade to OS X was promised, but it was a long time coming and when it first appeared, it had a lot of problems. After struggling for a couple of years with the Classic solution, I recommended that we migrate the database to FileMaker. I recommended a FileMaker professional; I had experience with Filemaker, and had designed a number of databases, but I learned how to use different capabilities as I needed them – this project deserved someone more familiar with the nuances. It was a wise decision, because it turned out to be a complex project, and took the guy a month or so to get ready for deployment.

No one (other than myself) was very happy with the FM solution, because it meant having to learn a new system. But they gradually came around to it. Shortly thereafter, Helix came out with a stable OS X build for the server and the clients and I told the boss at the company; he made the decision to go back to Helix, which was still working well for them until I retired a few years ago. But for a few years there, Helix was the foremost reason I would get support calls from that company, and even if I was there for something else, I was constantly helping someone remember how to get into the database server.
 


Amazon disclaimer:
As an Amazon Associate I earn from qualifying purchases.

Latest posts