>>Joining intermediate result and table employee_queue_schedules (Cartesian product)
>
>BING BING
>

Yes, I was thinking of using select .. from Table one inner join (select ... ) step1. The select is quite complex, so it would not be an easy task to re-arrange it, but I'll try.

>Probably the bottleneck - Sorry, the query is to long to grok fast.
>BUT: I've rearranged similar joins where vfp thought cartesian profuct was needed
>into 2 or 3 "filtered" selects,
>(rerunning the second query part and adding a
>where pk not in (Select pk from previos select_result
>describes "filtered")
>and the speed gains were sometimes drastic on tables both near the 2 gig border.
>
>Perhaps more elegant solutions would have been possible by defining specialized
>indices, but tests were too time consuming - good enough for that use case.
>
>Hint: "Split" your code so that 2 queries run:
>One to create the intermediate result as a cursor or table
>One to Join it with employee_queue_schedules
>
>Probably the second query will take most of the time, whereas the first query will be relatively fast. *If so*, you have
>a) provably identified the botttleneck inside ther query (Just time it)
>b) reduced the complexity of the bottlenck
>c) testing alternatives for the second join should be easier
>
>Hint: Build a Start Scenario and work of programmatic versions first to get the expressions correct by working of opened tables and the text/code from sys 3054. Works better for me for experimenting...
>
>Just having both tables physically to inspect and tweak the SQL for the last join helps as well as the possibility to query for selectiveness of criteria.
>
>regards
>
>thomas