>Your right about the speed issue. The program I'm calling wants a table and index. Earlier I had decided to create a table and then index but I'm indexing on 24,000 records - not fast or good. So I guess I'm back to finding a way to create an index that act like a filter.
You can create an index that filters records, but that would be for this one specific case.
How you solve this depends somewhat on what you want to do.
For instance, to process all the desired records, just use an index on the desired field - no special index required. For instance, you wanted fields that started with "S", right? SEEK for the desired value ("S" in your example), and SCAN WHILE SomeField = "S".
To show the data in a report, SELECT ... FOR SomeField = "S". Rushmore Optimization should be quite efficient, if you have an index on the field.
To show the data for edition by the end-user, you might user a parameterized view.
HTH,
Hilmar.
Difference in opinions hath cost many millions of lives: for instance, whether flesh be bread, or bread be flesh; whether whistling be a vice or a virtue; whether it be better to kiss a post, or throw it into the fire... (from Gulliver's Travels)
