Subject | Re: [IBO] Dealing with complex queries |
---|---|
Author | Robert martin |
Post date | 2008-07-08T20:45:22Z |
Hi
My understanding is that threads should not have direct access to visual
components (otherwise you get strange / random crashes). You could
synchronise the calls to the main thread but I suspect it might also
cause problems (note that MS used to use this system for its progress
indicators and stopped doing it).
Might give it a try anyway :)
--
Rob Martin
Software Engineer
phone +64 03 377 0495
fax +64 03 377 0496
web www.chreos.com
Wild Software Ltd
Woody wrote:
My understanding is that threads should not have direct access to visual
components (otherwise you get strange / random crashes). You could
synchronise the calls to the main thread but I suspect it might also
cause problems (note that MS used to use this system for its progress
indicators and stopped doing it).
Might give it a try anyway :)
--
Rob Martin
Software Engineer
phone +64 03 377 0495
fax +64 03 377 0496
web www.chreos.com
Wild Software Ltd
Woody wrote:
> From: "Svein Erling Tysvær" <svein.erling.tysvaer@...>
>
>
>> Occasionally, there is a third, obvious option: Simplify the query. I'm
>> still on Fb 1.5 myself, but assume that a few of the queries I've written
>> throughout the years could benefit from 'SELECT FROM (SELECT...' (Fb 2.0,
>> I think) and particularly 'WITH [RECURSIVE]...' (Fb 2.1). Though, of
>> course, there will still be lots of optimized queries that run slow, and
>> that one either have to live with being slow, redesign the database (that
>> can in some cases be a fourth option) or use one of the options Geoff
>> suggests.
>>
>> As for your 'thread moving' thing, if it is a complex where clause that
>> makes the query slow, you could have the time consuming query in one
>> thread and then (after it finishes) just look up the primary keys (or
>> whatever the time consuming query returns that could be used in a where
>> clause) it returned in a separate query in your main thread (note that I
>> know too little about threads and may overlook complexity).
>>
>>
>
> Can't you put the animation in a separate thread instead of the query? That
> way the animation should still get it's own time slot to do it's thing while
> the query chugs away doing it's thing. I've used that technique before and
> it seems to work for most situations.
>
> Woody (TMW)
>
>
> ------------------------------------
>
> ___________________________________________________________________________
> IB Objects - direct, complete, custom connectivity to Firebird or InterBase
> without the need for BDE, ODBC or any other layer.
> ___________________________________________________________________________
> http://www.ibobjects.com - your IBO community resource for Tech Info papers,
> keyword-searchable FAQ, community code contributions and more ! Yahoo! Groups Links
>
>
>
>
>