Gregory,

yes your example is reight. I'm not sure about the speed thing, but thats only missing knowlegde. All I know is that the records will be listed in the order of index. I have no idea how this will effect the way they are retrieved and buffered - for long tables there might be a problem too. Lucky as I am I never had problems with such large tables.

That's a kind of code obfuscation. If I mean FOR I do FOR.

I would prefer a SELECT SQL -> SCAN anyway.

I think the basic problem (Jerrys, not yours) here is the misunderstanding of the way the scope WHILE is working. Thats all what I like to point out.

Agnes
>Agnes,
>
>The question was why there were different results
>
>I know that a FOR does not order if there is no order set
>
>But for the second example you need an order set for the 'scan rest while' to work
>
>On a sidenote - an index set + seek() + Scan rest while() is faster than a scan for in larger tables
>
>Are we in agreement ?
>
>See this
>

>	create cursor pp ;
>	(	inv	c(6), ;
>		PK c(4) ;
>	)
>	insert into pp values ('000033', '0001')
>	insert into pp values ('000033', '0002')
>	
>	insert into pp values ('000099', '0001')
>	insert into pp values ('000099', '0002')
>	insert into pp values ('000099', '0045')
>	insert into pp values ('000099', '0046')
>	
>	insert into pp values ('000033', '0045')
>	insert into pp values ('000033', '0046')
>	
>	index on inv tag inv
>	
>	set order to
>	
>	&& (1) output
>	&& 0001
>	&& 0002
>	
>	mkey='000033'
>	seek mkey order inv
>	
>	scan while inv=mkey
>	  ? '(1) ', PK
>	endscan
>	
>	
>	&& (2) output
>	&& 0001
>	&& 0002
>	&& 0045
>	&& 0046
>	set order to inv
>	mkey='000033'
>	seek mkey order inv
>	
>	scan while inv=mkey
>	   ? '(2) ', PK
>	endscan
>