1 Reply Latest reply on Jun 15, 2007 7:43 PM by rgrzywinski

    flash.data.SQLxxx uses asynchronous callbacks, could there be option to change?

      Firstly, if this is entirely the wrong place to discus this or suggest /request a change then I'd appreciate guidance to where the best place is. It's not what I would consider a bug report, it works fine but I find it hard to use personally.

      Having spent a couple of days porting an application from it's existing sqlite access ( a socket server written in neko/haxe using xml as data interchange) I'm finding the callback mechanism of database access to be a bit of a PITA!

      Unfortunately, to build the objects I need in the flash space, I often need to query the database between 2 to 6 times for each one. In every other language I've used to access sqlite the results have been available immediately (as far as my code is concerned) without having to arrange a callback function and subsequent action for each query.
      Writing a callback for each query makes my code very lengthy to write and hard to read/follow :(

      Is there any known way to simply/rationalise this process? I've not had to do this before. help welcomed.

      I appreciate that I can bend/improve my SQL to minimise query counts, but unfortunately I am stuck with the database schema so theres only so far I can go with that.

      I also appreciate that for simple queries the callback mechanism fits in very well with the sort of asynchronous programming one would do for accessing data from a web server, so it should be a good fit for web/flex programmers in terms of that way of working.

      But for me, working on a local sqlite DB and knowing that queries are very fast and won't really stall my app, the callback way of working is really not working too well.

      Any chance of providing a "synchronous" API for sqlite as an alternative , in much the same way as synchronous/asynchronous APIs are provided for file access?

      It would be greatly appreciated as far as I'm concerned ...

      Otherwise, any comments, help, or explaination/information would also be much appreciated.