I am doing a revdb_query in a function; my database id is a global. I am in a handler that has done a few queries, then calls said function. The sql has been reduced to a dummy select * from table. Earlier cursors are closed, and I use sqlite.
I use 'answer question ...' and the one right after the query ( and all logic after that) is never reached. One thing I'll try is open/close a connection in the function. --Maarten On Monday, May 9, 2011, Pete <[email protected]> wrote: > Hi Maarten, > Can you describe in a bit more detail what happens? Are you using > revDataFromQuery or revQueryDatabase to issue the SELECT? If it errors out > silently, how do you discover that it didn't work? > Pete > Molly's Revenge <http://www.mollysrevenge.com> > > > > > On Mon, May 9, 2011 at 1:27 PM, Maarten Koopmans <[email protected] >> wrote: > >> I'll try that and maybe sqlyoga, but I am using sqlite with only >> milliseconds in between. But query results as arrays etc. Sounds like >> a missing piece, so while typing I have decided to give sqlyoga a try. >> >> --Maarten >> >> On Monday, May 9, 2011, Bob Sneidar <[email protected]> wrote: >> > How long are you leaving the connection idle? SQL typically has >> connection timeouts built in so that someone cannot use up all the available >> threads and then dump them without terminating them as a means of denying >> service. >> > >> > When working with SQL I like to open/reconnect, make my queries, then >> disconnect right away without any user interaction. Otherwise, a user could >> leave an error dialog open and not respond until after the database times >> out. >> > >> > I usually have in my stack or database connection card scripts for >> initializing and making the connection, idling the connection (which is >> really a disconnect) and closing the connection. To SQL this results in >> either a connection being made, or else a disconnect, but to my apps after >> the first connection is made, I set a state wherein I know I can proceed >> after the first connection is made because I know the database is there and >> responding to queries. Hence the "idle state". >> > >> > I wrap all my sql connection/query commands in a try/catch statement so >> that if an error is generated, I call my disconnect handler first, then >> alert the user that an error has occurred. This has eliminated virtually all >> the normal SQL issues I used to have. It's also good programming practice >> for SQL. >> > >> > Of course, SQLite is a local file (typically) so this is not as much of >> an issue, but still I believe there are default timeouts you can encounter. >> > >> > Also, consider seriously, Trevor DeVore's great SQLYoga utility, which >> takes most of the pain and suffering out of working with SQL. You can return >> queries as lists, arrays or records, which I think are a special kind of >> SQLYoga array. >> > >> > Bob >> > >> > >> > On May 9, 2011, at 10:26 AM, Maarten Koopmans wrote: >> > >> >> Hi, >> >> >> >> I have a simple "select * from table" against a sqlite dbid in a >> function, >> >> Livecode 4.6.1 on OS 10.6.7 >> >> >> >> For some weird reason it errs out, silently. The only reason I can think >> of >> >> is that I didn;t close my cursor in a previous call, but other than >> that, I >> >> am "snow blind". Anybody ever seen this before? >> >> >> >> --Maarten >> >> _______________________________________________ >> >> use-livecode mailing list >> >> [email protected] >> >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> >> http://lists.runrev.com/mailman/listinfo/use-livecode >> > >> > >> > _______________________________________________ >> > use-livecode mailing list >> > [email protected] >> > Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> > http://lists.runrev.com/mailman/listinfo/use-livecode >> > >> >> _______________________________________________ >> use-livecode mailing list >> [email protected] >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode >> >> > _______________________________________________ > use-li _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
