Okay, you guys are correct. I assumed he was talking about a UI where he was attempting to filter using SET KEY. And, for my experience, a view usually turns out to be the best solution for selecting specific recirds in a UI-- if not always the fastest. But this situation may be differn't.

My "You can't" only referred to the ability to the limitation that SET KEY works on the current index only.

So, to amend my hasty statement, I would recommend using a view for selecting a record set in most situations, unless you need SET KEY or SET FILTER for a specific procedural process. You can go through all sorts of contortions attempting to select without views (or just SQL) in a UI, but I would recommend avoiding them unless a view isn't workable.

Even in a table-based app, I find I have a lot more flexibility by issuing a SQL-SELECT statement into a cursor used for a grid and relating back to the source table than having to worry about SET FILTER. After all, if you're filtering records in a UI isn't it usually to present them to the user? Usually in a grid?

And as an end-user of apps that allowed me to set a filter, I thought it was too easy to forget about the filter and then "my records disappeared." But obviously, others have other opinions.


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>You can't. That's why SET KEY TO isn't very wonderful. Why not make a view? Then you can select whichever records you want very quickly in whatever order you want. You could try SET FILTER TO, but it will be horribly slow.
>
>>Set Key to is a wondeful command. But the problem is that is I change the index i loose the recordset. How can i change the index and keep the same recordset i get when i use set key to command.
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
>Not sure I agree there Dan, on two points. First off, SET FILTER isn't necessarily slow, if it's an optimized expression (it sounds in this case as if it would be).
>
>Second, there may be a workable solution using SET KEY (depending on the circumstances). If this is a case where Francisko will frequently or always want the same order within the SET KEY group, he could use a concatenated index. That is, set the index on LastName + FirstName, set key based on LastName, and the resulting set will still be ordered on FirstName within the SET KEY result set.
>
>This is not perfect: this "solution" results in a longer index tag, and also requires that SET EXACT be OFF for at least the duration of the SET KEY. But if this technique is crucial to his app, and only SET KEY is giving him the speed he needs, it certainly is possible. You can't say "you can't" as you did above. That's not true.