Subject Re: [firebird-support] Multiple rows in singleton select
Author Marcin Bury
Hello

> I don't know how, in the past, you got away with the multiple rows problem
> but I can only suppose that you are encountering this problem only where
> you really do get duplicate ids.

Helen, there is duplicate IDs since they are taken from primary key of MGP_ROLE
table

Sorry typo here - should be there is No duplicate IDs

>
> I see the problem as deeper than looking for a workaround to avoid the
> exception. If you have some redundancy in that structure, then you have
> two choices, as far as I can see, viz.
> either

Few words to describe the structure:

MGP_ROLE is a table that contains information about paper reels (the big ones
used to print the newspapers and magazines).
MGP_PROT_REKL is a table that stores document header of reclamation report of
damage reels.
MGP_PROT_REKL_POZ is a table that stores ID's of damaged reels and also some
detailed info about the damage.

As you can see there is nothing fancy in the structure.

> 1) write an executable SP that is called by the main procedure in lieu of
> the INSERT INTO....SELECT FROM structure, making certain that the
> RETURNING_VALUES from the called procedure returns only the exactly correct
> set
> or
> 2) add sufficient criteria to your WHERE clause to ensure that the SELECT
> can target one and only one row in the subquery
>
> As long as you are getting multiple IDs that meet the WHERE criteria, you
> have a data integrity problem: either you need to add structure to allow
> the 1:many relationship, or you need to remove the redundancy that is
> making it possible to violate a 1:1 relationship.
>

Maybe I didn't catch the thing

Is the INSERT INTO A_TABLE SELECT ... method for inserting whole set of records
in one shot or not??

If so what is the difference between two sets:

"PIG";843;842;226417;0;"" -> this one ends up with error

and

"PIG";79;78;206248;0;""
"PIG";80;78;206249;0;""
"PIG";81;78;206250;0;"" -> works every time I execute the procedure with
parameters giving this set.

The worst thing is that from the time when error occured this procedure was
executed more than 20 times succesfully no matter inserting one or more records
to the MGP_PROT_REKL_POZ :-(

Marcin