If there is a new entity that uses automatic primary key generation, there may be a
primary key value assigned to the detached entity. If this primary key was generated
from a database sequence or table, the operation to generate the number may have been
rolled back with the transaction. This means that the same sequence number could be
given out again to a different object. Clear the primary key before attempting to persist
the entity again, and do not rely on the primary key value in the detached entity.
Another difference, hinted at earlier, between using IDENTITY and other id generation
strategies is that the identifier will not be accessible until after the insert has occurred. While no
guarantee is made as to the accessibility of the identifier before the transaction has completed,
it is at least possible for other types of generation to eagerly allocate the identifier, but when
using identity, it is the action of inserting that causes the identifier to be generated. It would be
impossible for the identifier to be available before the entity is inserted into the database, and
because insertion of entities is most often deferred until commit time, the identifier would not
be available until after the transaction has been committed.
This guy is skipping without a rope. At least, that's what this tiny ad said:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koophttps://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton