>>>>-- snip --
>>HTH
>>Barbara
>I never liked those key fields consisting of arbitrary numbers whose only virtue is their uniqueness. Since everyone seems to use them, it must be the right way to do things, but I like to try to use the key field to solve my ordering problems for me as well. In the app I'm thinking about now, my colleagues want to order the data on an "item_no" field which is a complex series of letters, numbers, and a decimal point. They want the numbers in it to order like numbers. I wrote a function which loops through the key string and generates a key which will give them the correct order when used as an index. That way, there are no UDF's in any index expressions or query expressions to slow things down. I think I can get away with this, because my colleagues recognize the need to make the records unique and are willing to add some data to make them so, for their benefit and mine. (I realize that this is a luxury we don't all have.) After they have done this, I figured I would then make
>the index PRIMARY and use a trigger or error trapping or something to handle attempts to create duplicate records. Do you think I will get away with all this, or am I getting myself into trouble?

there are two reasons to have key fields -- first is to set relations between tables. these should be the unique id type... second is to help client find information he needs -- indexes on name, zip code, whatever... both are important.