Re: BUG #1864: Strange behavoir of batches

Angelo Neuschitzer wrote:
>>> In my Program there were 3 blocks of inserting done in a row. 5
>>> blocks of
>>> insterting per call.
>>>
>>> first block insterted 93 rows (in table A)
>>>
>>> second instered 82 rows (in table B)
>>> third 2 (in table C)
>>> fourth 9 (in table D)
>>> [whereas Tables B,C and D have a reference on Table A]
>>>
>>> fith entered a reference to all 93 rows of (table A) in table (E).
>>>
>>> in the fith block at row 82 the batch failed because It did not match
>>> the
>>> foreign key constraint of table A TO table D
>>
>>
>>
>> And was this correct or not? Did row 82 reference a valid row in table
>> A  or not?
>
>
> Was corrrect. the row was not exsistent (afaik. Its very hard to
> relocate a row in Table A without a reference in the tables B,C or D)
> I also should mention that the first 93 INSERTs had no explainable
> order, but were always in the _same_ order.

If the foreign-key from table E couldn't find the corresponding row in
table A, then it's supposed to raise an error. So - if there is a
problem it must have happened when inserting the data into table A.

I'm not a Java expert I'm afraid, but there are a couple of things that
seem worth checking:
1. Make sure you check the result-codes when inserting these batches.
    Put some inadmissible data in and check you get an error back.
2. Does the problem go away when you just use single statements within a
transaction rather than addBatch() - that would narrow down where the
problem is.

--
   Richard Huxton
   Archonet Ltd