Thanks for the reply, the 'ORDER" clause doesn't affect the speed. It seems that the 'join' is the problem. I can read another table by itself in 2-3 seconds for almost 2000 records. In the original example there are indexes on DELETED() and the "code" field and the "name" field for both tables.

Rgds
Petras

>Also, Petras (via Michael)
>
>Is the ORDER clause slowing things down? What is the speed if you don't order it? And do you have an index on the NAME field?
>
>HTH
>Barbara
>
>>Hi Petras.
>>
>>Please correct me if I am wrong.
>>
>>I always thought using "==" for comparison caused the SQL SELECT to take longer?? Will just using "=" work for your situation?
>>
>>The ORDER BY clause may add some time looking at the size of your result set.
>>
>>Also Browsing table(s) can seem faster since only the viewed records are retreived. Then as you page down the others are retreived.
>>
>>-Michael M. Emmons
>>
>>>Hi, the following VFP 5.0a program takes on average 20 secs to read under 500 records. The files are on a SCO Unix server with the "samba" network agent connected to Win95 PC's over a 10MB network connection. A VFP "browse" for the same files and fields is almost instantaneous.
>>>------------------------------------------------------
>>>USE "\\unix\disk1\maindata\crd\crdmst.dbf" IN 0 SHARED
>>>USE "\\unix\disk1\maindata\z\zdna.dbf" IN 0 SHARED
>>>
>>>nTIME=DATETIME()
>>>
>>>SELECT crdmst.name, ;
>>>ALLTRIM(pstl_adr_1)+','+ALLTRIM(pstl_adr_2) as address, ;
>>>ALLTRIM(pstl_city)+','+ALLTRIM(pstl_state)+pstl_pcode as city, ;
>>>balance,creditor FROM crdmst,zdna INTO CURSOR cdm NOCONSOLE ;
>>>WHERE crdmst.creditor == zdna.code ORDER BY 1
>>>
>>>=MESSAGEBOX("Time:"+STR(DATETIME()-nTIME)+" Seconds")
>>>
>>>CLOSE TABLES
>>>------------------------------------------------------
>>>Any help would be deeply appreciated. I'd hate to contemplate VC/VB or Delphi.
>>>
>>>Rgds
>>>Petras