|XP is just a number|
Everybody knows that when a transaction fails, you restart it from the beginning. You don't just drop your change on the floor. That would be silly.
The point is, there's nothing you can do about it, being you haven't locked the table or records.
So you're imagining that we can put the entire update in one big blob of SQL and run it without checking for any error messages? That seems... optimistic. But at least we can agree that using a perl-based cache "to speed things up" is a Bad Idea, right?
If the statement is insert where not exists, there should be no errors, unless something unrelated (like not enough space) crops up. In which case you do not want to handle the error automatically.
The cache i referred to in the database cache where table are often kept for future statements.
if you hold too many row locks on a table, doesn't Oracle automatically upgrade it to a table lock? And isn't holding a table lock for the duration of the import operation potentially disruptive to a busy database? Maybe we need more context than the OP has provided.
If you lock a table with lock table, or records with select for update, iirc, noone else can touch those records. During a single transaction, however, other users are running off the redo cache. So, it's a bit different.
We should not need more context, being this is a pretty standard import operation.