Hm, my communication skills are letting me down again. The retrieval of the rows is not slow. The end result set is only about 10-15 rows on average, but the gymnastics to get them in SQL is terribly complex. I had our DBA guys optimize the SQL, but even so it takes several minutes just to *start* returning rows, even in SQL*PLUS, for example.
As to making a reusable thread, I've lately been toying with the idea of having a long-running process act as some kind of IPC server, and having the GUI just be a client of that. The client might look something like:
$res = $srvr->ask($SQL,@params); if ($res == SRVR_ACK && SRVR_WAIT) { # set up something to check back for results later } else { # deal with the results }
I think that's kinda-sorta what you're talking about, but I just can't seem to wrap my head around this, so I might be wrong. Thoughts?
In reply to Re^2: Long-running DB query makes Tk application unresponsive
by radiantmatrix
in thread [solved] Long-running DB query makes Tk application unresponsive
by radiantmatrix
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |