>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.

VFP doesn't respond to Windows events within the scope of an atomic VFP instruction; this doesn't indicate that VFP has necessarily crashed. So the Task Manager message is misleading here.

Depending on how you've set up the Swap File(s) under NT, you may be thrashing out in virtual memory. Try setting SYS(3050) to a value less than or equal to physical memory (I'd try SYS(3050,1,64000000) and SYS(3050,2,16000000) for foreground and background limits respectively to limit VFP's appetite for memory.)

>Is there a memory limit or somekind of trap with vfp6?
>
>Thanks.
>Eric.