>>>>>So I have all these keys, which are both unique and useful for ordering. When a record is added, I get the values from the textboxes, make a key with genkey(), and INSERT INTO tablewhatever(keyfield, field1, etc.) VALUES newkey, fieldval, etc. I'm content to go on doing that, but some people here (I believe Barbara Paltiel was one) have said that primary keys should only be used for their uniqueness, and should be generated by incrementation or random methods. I didn't understand their reasons, and I didn't want to ASSUME, though I'm free to SUPPOSE, that I'm smarter than everybody else.
>>>>
>>>>
>>>>I want to ask you one more question, suppose if a user modifies any of these fields then how will keyfield's values be changed, I mean isn't there any chance of duplication...
>>>
>>>All my apps do keyvalue = genkey(value1,value2,value3), then INSERT INTO table(keyfield,field1,field2,field3) VALUES (keyvalue,value1,value2,value3) and then TABLEUPDATE. That is a good point, though. Right now, if you attempt to enter a duplicate, there is an error message and a TABLEREVERT. In my current standalone environment, no harm is done. I don't want to allow users to make duplicates, as defined by field1, field2, and field3. I realize that, in a multi-user environment, the potential for harm is greater. But I'm not sure what I'm risking, doing it my way...
>>
>>So, that means, if a user keys in the wrong data first time, then he can't change..
>>
>>secondly, how will be the keyfield value affected, if another field is added..
>>
>>Conclusively, i will say its risky, but as you wrote before, you can judge all the advantages and disadvantages of the above method, and if you think its fine then ok..
>>otherwise make a seperate unique field.
>>
>>I asked you all these questions, because I was keen to know if there is any other method which can substitute the standard coding, so that I can also use in my projects but speaking honestly, I will stick to unique field system only..
>>Thanks for taking out your time and giving me replies...
>
>If a user keys in the wrong data the first time, he changes it, then the key is changed, then I'm completely dependent on the RI to cascade the change or correctly TABLEREVERT, which Barbara has just told me is very risky, and reason enough not to do it this way. Therefore, when I get all the tables together, I'll probably make an incremented key.
>
>If another field is added which affected the uniqueness of each record, I would have to change my genkey function and rekey everything. That would be inconvenient. If my generated field was not used for keys, I wouldn't have to bother unless the new field also somehow affected the order of the records. It's not likely to happen to this particular database, but it is something to think about.

See, that is what.... It is not flexible as a unique key, because once your unique key generation is perfect, you don't need to worry abt. anything and simply, you can go on adding fields, let the users change fields to anything....

maybe for the time being (as your keyfield method is working) you can carry on with it, but sooner or later you will have to change.. Choice is yours...