At 10:06 PM 9/01/2007, you wrote:

>Hello Helen, thanks for your help on my issue!
>
>The following insert-statement causes the pk-constraint:
>
>insert into subscriber_resources2
>values (null, :p_resource_ins, :p_carrier_import, :p_carrier_imp_date,
> :p_carrier_export, :p_carrier_exp_date, :p_cov_id, :p_date_activ
>e)
>
>The pk-constraint is on the column which is provided with the value
>of the parameter-field "p_resource_ins" which contains a varchar(20)
>value, which contains phone-numbers. These have to be unique.
>and the parameter which I want to write into the table is provided
>like this before:
>
>p_resource_new = p_resource_root || cast(p_counter as varchar(2));
>p_counter = p_counter + 1;
>p_resource_ins = null;
>p_resource_ins = substr(p_resource_new,1,20);
>
>As You can see, the uniqueness is provided by increasing a counter.
>The issue is just to extend phone numbers from (e.g.) '0561-4711' to
>'0561-47110', '0561-47111', ... '0561-47119'. Nothing else.
>I checked the stuff out by debugging and it worked, not in run mode.
>What's up here?

The pseudo-uniqueness trap! Two different transactions could create
the same key value - the first to post the change will win - hence
the uniqueness violation. Now, in terms of your business rules, this
is what you WANT.

Use a different method to assign new phone numbers. There are
several different techniques, each with its merits. You might like
to read up the TechInfo sheet "An Auditable Series of Numbers" at
www.ibobjects.com/TechInfo.html.

But hasn't somebody ever taught you not to use user data as a primary
key? By all means place a UNIQUE constraint on the phone number -
but use a generator for the PK.

./heLen