>>>>Hi everybody,
>>>>
>>>>How can I randomly select n (110) codes from some huge table, so these codes would be unique? I'm trying to create a test case now...
>>>
>>>

>>>*   Assumes V. 7 for RW cursor, but can emulate in prev versions.
>>>
>>>SELECT cCodes, .F. AS lSelected ;
>>>   FROM BigTable ;
>>>   INTO CURSOR UniqueCodes readwrite ;
>>>   GROUP BY cCodes
>>>
>>>lnCodes = _Tally
>>>
>>>SELECT UniqueCodes
>>>
>>>*  This approach to using RAND() will give randomized numbers, but
>>>*  the same sequence each time it is run (this is helpful for testing
>>>*  to determine that changes in execution speed are due to algorithm
>>>*  changes rather than the distribution of the values).
>>>
>>>*  If you want a different series between runs, you can issue a
>>>*  preliminary call to RAND (-1) which will seed with a value
>>>*  from the system time clock. For that, uncomment the line below
>>>
>>>*  = RAND (-1)
>>>
>>>lnSelected = 0
>>>DO WHILE lnSelected < 110
>>>   GO lnCodes * RAND () + 1
>>>   IF NOT lSelected
>>>       REPLACE lSelected WITH .T.
>>>       lnSelected = lnSelected + 1
>>>   ENDIF
>>>ENDFOR
>>>
>>>SELECT cCodes ;
>>>   FROM UniqueCodes ;
>>>   WHERE lSelected ;
>>>   INTO CURSOR SelectedCodes
>>>
>>>

>>
>>I'd rather create cursor SelectedCodes and insert records into it from within the Do While lnSelected<110 loop, so you wouldn't have to run a select against a long table in the end. But other than that, this seems to be the ticket.
>
>Dragan --
>
>Thanks for your thoughts.
>
>From Nadya's comments, it's clear that the original table was large. But, it wasn't clear the number of codes. Even ZIPs only number about 50,000 at last count.
>
>So, if the codes are a relatively small number (and I'd put ZIPs in that category), I think either approach would work well. If that assumption is incorrect, then I'd agree, that populating a new cursor in the loop would be the way to go.
>
> Jay

Yes, it was for ZipCodes. Anyway, I suspended my tests for now, so I hadn't chance to try either of suggested ideas...