Hi!

When query is full-optimized, it is quite quick. Your query might be slow because another reason. the scheme used by VFP to perform such query is following (I show only records selecting part):

Filter records in the T1 using index. This is as quick as SET KEY command.
Filter records in the T2 using index. This is also as quick as SET KEY command.
For each record in T1 find al records in the T2 using index (much like SET RELATION/SET SKIP TO).
If no records, include .NULL. into result, otherwise get record from T1 + all records from T2.

I guess you require to examine more old approaches in VFP to work with data tables. Take a loot to the INDEX command, SET RELATION/SET SKIP TO, SEEK command and function, lookup() function, INDEXSEEK(), SET KEY, SER ORDER. Find also the full description of the binary search algorithm in the binary tree and a format of the index file in VFP. You will understand that VFP really does everything required to optimize your query as good as possible.

Other reasons why your query might be slow:
the network is slow
the indexes file is large
the record size in the table is large,
you're using numeric or character field type for primary keys
you did not set up VFP enironment properly for as best speed as possible (there is an article about this in MSDN VFP Programmer's guide). For example, SET TALK OFF, remove standard toolbar that displays current database, close 'SET' window, close all debugger windows, hide status bar by SET STATUS BAR OFF, set _VFP.AutoYield=.F., SET EXACT ON and SET ANSI ON etc etc. A lot of envoronment settings and development things can cause slow running of the code, and teh SELECT statement in particular.

HTH.

>Vlad
>
>If you tried:
>
>SELECT * ;
>FROM T1 ;
>LEFT OUTER JOIN T2 ;
>ON T1.Key = T2.Key ;
>WHERE T1.a = '' ;
>AND T2.bb = 'qwwe'
>
>And Table 1 had 37000 records, and table 2 had 20000. It would be very slow.
>
>Can you seem my point, because the Select will be running from Variables, these variables can sometimes be blank, depending on the criteria.
>
>Sorry, I know I should have mentioned that earlier.
>
>Thanks
>Kev