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.