On Sun, 11 May 2008 12:47:29 +0200, Philippe Marschall wrote:

> 2008/5/11, Klaus D. Witzel <klaus.witzel at cobss.com>:
[...]
>> > > > >  Out of curiosity, what would it be that you intend to let the  
>> users
>> do
>> > > > > while longish queries are tickling the db?
>> > > > >
>> > > >
>> > > > If you use Seaside: reply to other requests.
>> > > >
>> > >
>> > >  Sure, goes without saying. *but*what*else* ?
>> > >
>> >
>> > Doing the usual GUI updates (hover, progress bar, whatsoever) so that
>> > the application does not appear "frozen".
>> >
>>
>>  We asked the users (releases 1-2 where developed by our  
>> "predecessors", we
>> did the 3.x release series, the users where *very* well experienced :=
>> plagued by DB response time). Guess what they asked for.
>>
>>  BTW: progress bar update is #fork work.
>
> UI updates in general have to happen in a very specific thread.

Sure.

>> Furthermore, you'll earn credit if
>> you can predict the 100% base and the respective increments, of  
>> arbitrary db
>> queries which are performed on some dedicated server multi-user, predict
>> with a small epsilon (not like MS$ does it when they copy/move around
>> files).
>
> Progress bars in general have a indeterminate mode for such cases.

NP with me but, this is just an excuse from the IT-shamanes (not you nor  
me nor anybody else reading this ;) , for their inability to predict  
*time*.

>> >
>> >
>> > > > Cheers
>> > > > Philippe
>> > > >
>> > > >
>> > > > >  I ask with this background in mind: over several years I  
>> headed a
>> team
>> > > of
>> > > > > developers who produced 1.5 releases/year of a
>> > > > > (fat+GUI)client<->(shared+fast)db server app with
>> > > between 6
>> > > > > and 60 GB data etc, 50+ installation sites (institutions with  
>> their
>> own
>> > > db
>> > > > > server) and 100+ users, with 98% of the db data being updated  
>> over
>> night
>> > > > > (incrementally). We brought down the app's db response time from
>> minutes
>> > > to
>> > > > > seconds but still never found any reason for using non-blocking
>> queries,
>> > > > > because nothing much was there that could have been done by the  
>> user
>> in
>> > > the
>> > > > > meantime.
>> > > > >
>> > > > >  Do you just want to see non-freezing queries running or have  
>> some
>> other
>> > > > > reason for that need?
>> > > > >
>> > > > >  /Klaus
>> > > > >
>> > > > >
>> > > > > > Or, is it a bigger issue than just ODBC, something buried deep
>> within
>> > > the
>> > > > > VM
>> > > > > > and/or the FFI?
>> > > > > >
>> > > > > > Thanks,
>> > > > > >
>> > > > > > Rob
>> > > > > >
>> > > > >
>> > > >
>> > >
>> > >
>> >
>> >
>>
>>
>>
>>
>
>