🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

okay, here's the deal.

Published April 13, 2006
Advertisement
Okay, back to the subject. I futzed around with the Access/Jet functions built into Zinc, and it works beautifully. It's quick and easy. It's be an absolute cakewalk to do all of my persistent data-handling with it.

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 databasemdm.Database.SQLite.connect(filename:String):Boolean// close the databasemdm.Database.SQLite.close():Void// just returns true if the database was successfully openedmdm.Database.SQLite.success():Boolean// run a query on the opened databasemdm.Database.SQLite.runQuery(query:String):Boolean// get the number of records returned from the most recent querymdm.Database.SQLite.getRecordCount():Number// get a field from the most recent querymdm.Database.SQLite.getField(rowIndex:Number, columnIndex:Number):String// returns the result of the query as a [2]-dimensional arraymdm.Database.SQLite.getData():Array// get the most recent error in text formmdm.Database.SQLite.getLastError():String


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 :)
Previous Entry Yep, it's a two-fer
Next Entry SQLite glues
0 likes 0 comments

Comments

Nobody has left a comment. You can be the first!
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement