Even in this case running a query with a minimal possible number of tables included can give you an idea how much you can optimize the query.

>I agree, except that in our system Query is a separate application. So, I either should create a job consisting of multiple Query steps, which is quite inconvenient or try to optimize this query to the best I can... Another option would be to make selections based on TranMstr and SiteMstr (join to SiteMstr is needed, because TranMstr doesn't have a town field), and to join to CMRView in my application. But unfortunately, the first resulting table would be too big and I also has to change the logic in my own application...
>
>>Hi Nadya,
>>In cases like that I usually try to split the query into multiple steps
>>First, I would run query like follows and see how much faster it gets
>>

SELECT TranMstr.PropID, oJC.CurState as State, Date, Mortgage, Source, ;
>>ParentCode as Lender, extrWeek, extrYear ;
>>FROM TranMstr ;
>>where between date ctod('01/01/2001')and ctod('06/30/2001') and between Mortgage 1 and ,1000000000 INTO CURSOR Step01

>>
>>If it really speads up things than I'would join the rest of tables with this cursor or try some other combinations.