>The whole idea of Rollback is that, if
>the transaction is not to be committed (in entirety), then it is
>rolled back (in entirety).

this is ok to me.

In fact, I start a new transaction for every INSERT I have to do.

If no exception is raised, I commit the transaction ("officially" storing
the new record).

If an exception is raised, I want the transaction (i.e. the insert) not to
happen.

>What you need to do is trap the exception in a way that allows the
>transaction to continue.

I cannot figure out another way to write the code.

The only way I can understand that the insert/transaction is be cancelled
is detecting an exception

>What your exception code is doing is FIRST
>killing the transaction and THEN attempting to send a message to the
>user. Of course, by that time the exception has already been raised
>and the confirm dialog is fruitless.

I don't understand. The exception has been raised: ok. The transaction
(i.e. the single INSERT) has been killed: ok.

Now I want the user to decide if to go skip the offending record and
continue with the INSERT sequence or if he wants to halt the whole
data-pumping.

You are seeing something I cannot see.

>Create a proper exception handler to trap a rogue record, perhaps to
>log the offending record out to an external file, and let the
>transaction continue. Don't call Rollback unless you *want* the
>transaction rolled back.

It is ok to me to rollback the transaction, as far as 1 transaction= 1 INSERT.

>Also, look at taking explicit control of the transaction and
>deferring the call to Database1.Commit until the pump is complete.

IF I let the whole pump be 1 transaction, all your points would be clear,
but I started a new transaction for every INSERT, so I still don't see what
went wrong.

It would be very helpful for me to understand what should be the exact
coding, while keeping the concept 1 transaction = 1 INSERT.

Thank you

Duilio Foschi