How else can you use the delete/insert sql update feature for transactional updates?

>Larry,
>
>My *personal* opinion. . .
>
>It's probably OK as long as you make the facts CLEAR in relevant documentation.
>
>I also, personally would *not* do it. BUT I do accept that people WILL do what they *can* do. With me its more one of those "lines" over which I will not cross if I have any choice at all, and so far I have been able to do so.
>
>Cheers,
>Jim N
>
>>>Erik,
>>>
>>>------ huge snip
>>>>
>>>>I occasionally use a filter on indexes, but didn't think that it was allowed on primary indexes. Apparently so, but this leaves me pretty confused as to the definition of a primary key in the first place. I mean, I thought that an neforced unique key was just that... an enforced unique key. Can anyone clear this up for me?
>>>>
>>>>Erik
>>>____ end snip
>>>
>>>I guess its a bit like driving a car. You *could* drive on the other side of the road if you wanted to, even though you know you shouldn't.
>>>
>>>I see Primary/Candidate indexes in rahter the same way - there are things you *CAN* do, but it doesn't mean you should do them.
>>>
>>>regards,
>>>Jim N
>>As a general rule I have started doing the following with all of my tables as a part of a personal standardization to allow for the use of both the SQL update methods (update record and delete/insert). I came up with this to be able to keep transactional record of all the changes made to a table. I would like some feed back....
>>
>>All my tables have...
>>1) a field called "keyfield" character(18)
>>2) at least 3 tags
>> TAG NAME INDEX TYPE EXPRESSION FILTER
>> primary primary keyfield not deleted()
>> keyfield candidate keyfield
>> isdeleted reguar deleted()
>>3) keyfield default value = dtos(date())+sys(2015), which generates a unique key that I am 99.9% sure will always be unique.
>>
>>This way I can have a field that is normally unique for example SS#, but allows it to be changed without changing the primary field for that record.