> With your current setup, ARE you checking that following a
> successful 'check' insert, that the 'normal' insert has also
> been completed? What do you do if the one of them has
> failed? Can you get out of the code cleanly with 'check'
> completed, but not 'normal', which is exactly what seems to
> have happened ( on a couple of occasions ). So yes the
> problem is your code, but it may just be the way you are
> expecting it to work.

Yes, I'm checking these with comparing the return values of the
executeUpdate(toInsert) methods, and if check indicates a problem, the
client refreshes it's data from the database.
Now it could occur, that one record got stored in the check, but
couldn't get stored in the normal, but right after that the client
would give an error message and stop working (and will refuse to
start). But I found 2(!) records that were only in check db. This
means either that the executeUpdate returned a false value, or two
clients at the same time got the same glitch (I guess this is more
possible) and of course the possibility of my code being wrong still
lurks (and to make things easier, let us say, that it is in my code).

> I am not explaining myself very well, but I hope you get the
> picture. As you are finding there will be hiccups, and the
> trick is to pick them up at the time. I'm not sure you need
> to 'write' and then 'read' every time, but a check that the
> new record exists would not be a problem. But replicating
> the database to a second copy is better done in a separate
> procedure if you need THAT level of security.

All I need is to know if an inserted records really IS inserted and
will stay so (and gets saved to harddrive) :)
Thank you again!
John