Hi Sergey,

Some more info: I tried it in VFP 7 and it has the same problem. Only the time limit seems to be a little lower (95 seconds). The set on which it goes wrong has about 20500 records in table A. If I delete 500 records of this table the code works fine. The time to complete the query drops below the 110 (95 in vfp 7) seconds because of this delete. I tried the same tests on a slower machine. This machine has the same problem and the same time limits. On this slower machine I have to delete more than half of the records to get the qeury working and again this delete gets the time to complete it below the 110. So it really seems to be a time limit problem and not a number of records problem.

>Hi Mark,
>
>Are you running query against VFP data or some other backend? What's VFP version?
>
>>Hi All,
>>
>>I have a select statement which acts a little weird. It is a select into a cursor like this one:
>>
>>Select A.RecID, B.Date
>>From TableA A
>>Join TableB B on A.RecID = B.RecID
>>Group By A.RecID
>>Order By A.RecID
>>Into Cursor tmpCur
>>
>>I excecute this statement different sets of data. Every set is bigger than the one before. This statement gives me a cursor with the name tmpCur until the set of data makes the select take about 110 seconds. At this point the select stil works but the resultset is called something like GC4SBG4Q. If I make this statement into a View like this:
>>
>>CREATE SQL VIEW tmpCur AS ;
>>Select A.RecID, B.Date
>>From TableA A
>>Join TableB B on A.RecID = B.RecID
>>Group By A.RecID
>>Order By A.RecID
>>
>>And perform the same tests by executing Use tmpCur on the different sets of data the result is the same. If the select takes over 110 seconds the resulting cursor isn't called tmpCur but something like GC4SBG4Q again.
>>
>>This looks like some time out problem, but the select still work fine. What could this be??