Content

Not quite a Yegge long.

Announcing libflashfiler, the C library for digging yourself out of Delphi-shaped legacy holes

Monday 21 September 2009 - Filed under Uncategorized

If you’d rather not stick around for the story, here’s the library. It lets you do cool stuff like dumping your .FF2 databases to SQL scripts, ready to load into something that’s more usable.

In days long since past, Borland were a respected compiler and database vendor. Well, compiler vendor. Their database has always been kinda crap, even if they were widely used, and could run on the pathetic PCs of the day.

During this time, a lot of people decided to build applications with their Turbo Pascal (and later Delphi) tools. A lot of *these* people then decided that they needed a database.

For good reasons they chose not to use the Borland Database Engine (it is a heap of garbage), and for less-good reasons, they chose not to use a “proper” database that did anything a standard way. In any case, they ended up turning to TurboPower’s FlashFiler database, which (if used properly) can be reasonably swift, and is familiar to Delphi CRUD developers, since all the same RAD data binding crap still works just the same way. I would have said this was a bad thing at the time, but I wasn’t present (not everywhere, at least).

Fast forward several years. Anders Hejlsberg’s influence on the Delphi language design is long gone, since he’s now at Microsoft building the awesome get-stuff-done language C#. Despite glimmers of hope around compiling to .NET, etc, the Delphi language has stagnated to the point where approximately no-one actually uses it anymore. And TurboPower, who made all these component gadgets that no-one really needed but everyone bought and crammed into their applications anyway – TurboPower went bust, leaving everything that was cared about on SourceForge.

So although FlashFiler is not an attractive choice of database now, there’s a fair amount of legacy stuff built on it, including a LOT of data, which approximately nothing can read anymore. (That’s not quite true, you can give the NexusDB guys a pile of money for more of the same RAD drug, and they provide a half-baked tool that can almost import your FlashFiler tables and write them out to brand new, completely closed, works-with-nothing-except-Delphi NexusDB tables. Pardon me for not jumping at this offer. (It really is half-baked. It fails to pick up columns randomly, it corrupts data, and the GUI crashes horribly for no discernable reason).

Oh, and they were kind enough to release an ODBC driver that can talk to the original cranky GUI-only FlashFiler Server, which works, but needs to have a human attach each database you want to use, manually. You’d hope that it would be possible to hack the list of attached aliases behind its back, but that turns out to be a waste of time, since the alias list *is* a FlashFiler table. So, that’s hardly ideal for migrating *away* from a messed-up platform like this, or doing anything else vaguely automated.

So here’s libflashfiler. It’s a C library that directly reads the .FF2 tables, can read the schema, and provide forward-only cursors. There’s no SQL engine, this is just really simple. Simple enough to allow you to dig yourself out of a Delphi-shaped legacy hole, if you happen to be in one.

There’s also a sample app included which just takes a .FF2 filename on the command-line, and spits out a SQL script to import into your favorite “real” database.

2009-09-21  »  admin

Share your thoughts

Re: Announcing libflashfiler, the C library for digging yourself out of Delphi-shaped legacy holes







Tags you can use (optional):
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>