Database Interchange

[senrew]

I think I've exhausted my google-fu on this tonight, so it's time to ask the army.

Are there any database programs that run on a LC III under system 7 that will allow relatively easy file format exchange to some kind of modern application? Preferably without having to save to a CSV or anything like that.

 

[nglevin]

There's nothing I'm aware of that won't require a CSV export. Even the old AppleWorks/ClarisWorks databases had no good export story besides exporting to a comma separated plaintext ASCII file.

HyperCard might be your best bet. Between the flexibility of its scripting language HyperTalk (a good primer called the "HyperTalk Beginner's Guide" shipped with HyperCard 1.2.5, which can be found on pcamen's site), the HyperCard Online uploader, and WIP efforts like MACE to run 68k binaries on modern computers, HyperCard might be the only "database"/RAD development tool with several communities actively devoted to its preservation.

Heading in another direction, if you could find a copy of FileMaker Pro 4.1 for Windows, that should still work with some amount of finagling on Windows 10. The Mac version of FMP4 was the last to run on 68k Macs. I'm not crazy about FileMaker myself, but it ticks the most obvious box of "90s RAD friendly relational database program".

FileMaker has gone in a bit of a subscription-based RAD in the cloud direction in the many versions since. I don't expect export from modern FileMaker to FMP4 to work well (if at all). They do have documentation for FMP 4.1 still easily accessible in PDF format, so that's something.

On the other hand, if CSV import and export between two database programs is fine, Panorama X for Mac OS X is a relational database program from one of the first indie Mac developers that has some great import/export options, tutorials, RAD features, and a subscription model that's intended to be pay for what you use, seems pretty well thought out. Jim Rea, its developer, would probably be interested if you have any ideas for interop with old mac apps. TidBITS gave it a positive review.

I'm not aware of any other up and coming relational databases. The genre seems to have ossified around the time that $0.99 inventory tracking apps for your phone became a fad.

 

[senrew]

That's helpful. I hadn't considered HyperCard, but it does bring up another question I think I need to answer before I go looking for a specific application package.

"Personal" databases tend to be just that, personal. Their contents rarely need to be shared and typically reports take care of sharing specific information. First questions should be, where do I want to keep the actual data and do I need to access it from anywhere other than where I create it.

Technically, no I do not. I've been using my LC III as my primary "productivity" machine, and the idea for keeping the database(s) there is purely for fun. It means I would need to be sitting at that particular machine to access any of the data. The original question as to interchange was more brought on by the possibility of having to pull the data out and move it to a modern machine should I need to move my workflow related to it to a modern platform.

However, I think maybe I could look at this another way. Is there a database front end of some kind that can work against a database backend that would run on a modern machine? I could always create and host the DB itself in mysql on my home server and create a simple php interface that I could get to via icab or something like it. Unless there is a version of Filemaker that will connect to that kind of datasource?

Sorry for the rambling, but I wanted to make sure I got my thoughts out as I had them.

 

[nglevin]

However, I think maybe I could look at this another way. Is there a database front end of some kind that can work against a database backend that would run on a modern machine? I could always create and host the DB itself in mysql on my home server and create a simple php interface that I could get to via icab or something like it. Unless there is a version of Filemaker that will connect to that kind of datasource?

I think you are exactly one step away from banging on the reason why FileMaker* and its contemporaries don't make much sense today.

Namely, when a modern Mac already comes with Xcode, SQLite, and front ends to SQLite are as easily found as books to start programming for Mac OS X. Does a Java-heavy thing that talks to old middleware protocols like ODBC and Microsoft COM under the pretense of making things "easier" by hiding it all under a bundle of abstraction layers that are themselves hard to learn and program... does that still make sense? That's practically the phone app pitch, the one that started a consulting business boom around 2009 or so.

Put that same reasoning behind what you just suggested with a LAMP stack, where all you have is some "app" on a server that generates static HTML 2-or-so compatible pages on your local network that's backed by a database (Postgres! MySQL! SQLite!) and, well, you're already all the way there to a working solution that didn't require spending money on someone else's roach motel.

Relevant; Ted Nelson's Computers for Cynics, specifically the chapter on The Database Mess and how the enterprise software industry found a new way to strangle control away from their customers.

* - FileMaker, it never leaves the house without a suit and always drinks its coffee black. Unashamed to be Enterprise software with a capital "e". It isn't "bad" software. It absolutely does not have the same fun, creative spirit backing it as HyperCard, VideoWorks/Director, Fractal Design Painter, Fontographer, and so many other innovative, amazing, personally empowering apps from that late 80s period of the Mac.

It grew to become a better MS Access than Access, and remains unbranded as an Apple product because it's the most successful, blatantly Microsoft thing that Apple Computer, Inc has ever nurtured and raised. It lives because commercial database software is notoriously hard to migrate off of, guaranteeing some customers that Tim Cook can't justify completely cutting off at this time.

 

[senrew]

That video was interesting.

I guess, at the very least, the LAMP stack way of doing things is the best way to ensure forward-compatibility while still having some kind of front end to mess with the actual data within the older environment that I enjoy.

This does introduce the possibility of adding a new coding project to my to do list. System 7 friendly standalone DB front end, at least within the constraints of working specifically for the environment I'd be using for my personal needs. It'd be a start, and a fun way to finally make use of those MPW packages I have laying around