Would that I could. Trouble is there might be 100 sequences of each rte_no. Rte_let, directn. So I'd have to alter the key and seek up to 100 times, for each stop position that hasn't got a time value, to find that they've all got no time value, which makes them invalid and reportable. Once SEEKed, I'd still have to test the Time value for empty. Still, maybe even that would be quicker. Anyway, it seems the upshot of this thread is that there is no qucker way or "magic bullet" SQL line to do it faster.

Thanks

Terry

>Perhaps a more traditional SEEK would be faster? Seeking on the compound index.
>
>>Hilmar
>>
>>Thanks a lot again but I'm afraid that made no noticeble difference, i.e. it's still taking longer than the age of the Earth to run. I tried as below. The table's composite key comprises: RTE_NO + Rte_Let + DIRECTN
>>I did find out why one attempt seemed to go so fast though, on Friday. Note the second commented out line; it has a continuation ";" at the end, so the compiler was just ignoring the SQL as comment and it wasn't being done (I left it in to show - in the run it wasn't there of course).
>>
>>So back to the drawing board ...
>>
>>Terry
>>...
>>

>>* and	PADR( RZStop.County, 2)							= lcCounty ;
>>* and	not EMPTY( RZStop.TIME) ;
>>  Select DISTINCT TIME from	RZStop ;
>>  where 	PADR( RZStop.RTE_NO, 6) + RZStop.Rte_Let + RZStop.DIRECTN + STR( RZStop.Number, 3) + ;
>>         PADR( RZStop.Stop, 8) + PADR( RZStop.County, 2) = ;
>>  	lcRteNo		      + "A"	    + lcDirectn	   + lcNumber + ;
>>         lcStopNo		   + lcCounty ;
>> 	and	not EMPTY( RZStop.TIME) ;
>> 	to SCREEN NOCONSOLE  && Find any time value for this particular stop across all other sequences
>>