OH MY GOSH
why do you have an autonomous transaction!!!!!!!!!!!!!!!!!!
what was the thought process behind that???
also, if you have an "after INSERT OR DELETE" trigger and you only reference :new.rowid.... hmmm think about that....
I can give you three reasons for these duplicates.
1) first, if you insert and DELETE records - we'll definitely reuse rowids. rowids are unique within a table - period. We reuse them over time - absolutely. So if you delete from emp1, you are absolutely going to get "duplicates". We have to assume you do delete since - well - this is an after delete trigger..
2) second, you are doing something NON-TRANSACTIONAL in that trigger. If the triggering statement rolls back - guess what? You will have inserted the row into emp2 and committed it. IT WILL NOT ROLL BACK. The roll back will be just like a delete on emp1. So, you are back to reason #1 - you delete (everyone deletes - no one, NO ONE can say "we do not delete", if you insert - I am 100% sure you DELETE - because you rollback sometimes!!!!!!!!!!)
3) you assume we fire your trigger once for each row. Maybe we do, maybe we don't (hint: sometimes we don't, sometimes we fire it TWICE - we are allowed to, it has always been that way). This is why doing non-transactional things in a trigger (autonomous transactions, utl_file, utl_http, etc) is extremely dangerous.
http://asktom.oracle.com/Misc/something-different-part-i-of-iii.html http://asktom.oracle.com/Misc/part-ii-seeing-restart.html http://asktom.oracle.com/Misc/part-iii-why-is-restart-important-to.html I'm going to guess #2 is your culprit, your application attempts to create employee X - something failed - got their address wrong or something and the application rolls back. The end user fixes the error and tries again - and there you go.... reused rowid...Your use of rowid as a unique key is flawed, it'll never work long term - you'll need to find another approach.
LOSE THE PRAGMA - absolutely - it is a really bad use of this 'feature', a 'feature' I wish I could get removed from the database since it is almost always used *wrong* like this.
(yes, everyone that uses it right, I know you do - I don't care - 99.9999% of the usages of this 'feature' are wrong and dangerous and misunderstood. I would rather annoy the 0.0001% of people that know when and how to use it for the safety of everything else - like our data)