Licensing isn't really a problem. MS has a rather archaic "Access Deployment Kit" or somesuch thing that gives you a license to distribute Jet. Or you can just own a copy of VB, which apparently also comes with a Jet distribution license. Given that VB is free now, that's an easy one.
Problem is, I can't figure out a reasonable way to deploy the goldurned thing. It's not really a problem if you're running XP or 2000, as both of those apparently install with the Jet DLL's. The problem comes with Windows ME, 98, or even 95, which are still targets you have to look at when you're selling discount software. I'd likely have to bundle separate installers, and that fails the aforementioned "your grandma test".
So I'm back to SQLite. SQLite doesn't bother me at all. It seems like quite a capable little product with the most nonrestrictive license possible (aka public domain).
Problem is, its DLL API, while perfect for stuff like C, doesn't translate into ActionScript well, with things like callbacks and pointers and handles and things that ActionScript jettisoned.
So I'm gonna have to build a Zinc-Sqlite glue DLL. Since the Zinc folks already have three Database objects (MySQL, Access, and ADO) that are 90% identical, I followed their model. The following is about the minimal spec for a "Zinc compliant" SQL object.
// open the database
// close the database
// just returns true if the database was successfully opened
// run a query on the opened database
// get the number of records returned from the most recent query
// get a field from the most recent query
// returns the result of the query as a -dimensional array
// get the most recent error in text form
And that's it. Pretty braindead, actually. You can't even open more than one database at a time, not that it's a problem for me.
Digging into the SQLite API last night, the whole thing is basically a matter of the glue-DLL passing along query results to SQLite, then storing those results into a dynamic 2-dimensional array of strings, passing those values along to the caller, and wiping out that array when a new query is run. The only function that's remotely complicated is getData, because that returns data as an ActionScript array. That function can be written entirely in ActionScript as a combination of getField and getRecordCount, so not much problem there.
Yeah, it looks a bit hairy for a high score table, but I figure it'll be good to have some decent small/portable data handling in my future apps.
Yeah, I'm writing tools. I try to avoid it when I can, but I just don't see another solution that's even remotely as elegant.
Now it's just a matter of actually writing it. I'll have to start on Monday. I'll probably just write it in C. If the whole mess comes to more than 10k, I'll be disappointed with myself :)