>I have the following select in my code:
>
>SELECT ReComm.ident, ReComm.date_prev, ReCommD.*, ApSupp.name, ARCode.descr ;
>FROM ReComm ;
>LEFT OUTER JOIN ReCommD ;
>ON ReComm.ident = ReCommD.ident ;
>LEFT OUTER JOIN ApSupp ;
>ON ReComm.iddetail = ApSupp.ident ;
>LEFT OUTER JOIN ArCode ;
>ON ReCommD.Code = ArCode.Code ;
>WHERE WEEK(ReComm.date_prev,1,2) = THISFORM.ScnWeek.value ;
> ORDER BY ReComm.ident
>
>()
>Recomm:10387 rec, RecommD:21940 rec, apsupp:10672, arcode:13
>Recomm.ident, recommd.ident, apsupp.ident are unique key (integer)
>Arcode.code is unique key (char(5))
>
>It runs for ever and my NT4 (Workstation, 128MB RAM, enought disk space) tells me that VFP6 is not responding.
>It runs good if I specify a short range of Recomm.ident in the where clause. It runs good also if I take out both apsupp and arcode tables from the query.
>I thought that VFP6 would not crash on this. I can understand that it could run slow so you play with the indexes but "not responding"??? The same query in Crystal report runs in about 30 seconds.
>Is there a memory limit or somekind of trap with vfp6?
>
>Thanks.
>Eric.

It's still working. I guess your query is not Rushmore optimizable. If you use Crystal it just scans table, if you use non-optimizable VFP query, then VFP will launch creating temp indexes (WEEK(ReComm.date_prev,1,2) is the main suspect) and it can take long time, especially if you have bad luck setting wrong place for temp files.
There are few hints how to optimize queries. Besides creating appropriate tags you may also get better performance if you dissect complex Select to chain of smaller selects. For example, in your case you may first get smaller recordset filtered by WEEK(ReComm.date_prev,1,2)=THISFORM.ScnWeek.value . BTW, it's even better to use literal constant here, instead of form property.
Another improvement will be reached if you look realistically on number of outer joins you really need.