>Joining intermediate result and table employee_queue_schedules (Cartesian product)

BING BING

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