>Is it really like this?
>If I have a record with the ident (which is a unique index) = 1000, I deleted it, I cannot put 1000 anymore?

Deletion does not remove the record from existance, its imply makes it inactive in the context of SET DELETED ON. Primary and candidate keys must be unique at all times regardless of the SET DELETED status, since it can't be assured at any time, and there is always the potential of RECALL being issued against a record marked for deletion.

If you look back a week, there were a couple of threads on recycling primary keys, and some approaches to recycling keys and how to ensure uniqueness in the event of the (IMO) bad practice of recycling primary keys.

I don't recycle primary keys, and since I use primary keys as a mechanism for establishing table relations and not for ordering data, I also don't worry about the primary key being consecutively assigned, or even being assigned in an ascending or descending fashion. The use of surrogate keys (keys that carry no detail of the data properties of a record, only serving as a unique identifier) as primary keys removes the concerns over the possible side-effects of recycling keys (things like accidentally picking up 'children' of a previously deleted record with a given key. There's nothing quite like picking up a couple of dozen extra line items on an invoice because you've recycled keys and weren't immensely careful about relational integrity...)

YMMV. There are simple mechanisms for assigning new keys in every instance, and since it's fairly easy to provide a key space (the range of values available for use as a key) that's orders of magnitude larger than the number of records you might have, you give up very little.