On 2015-05-17, 3:19 AM, "ocs.cz" wrote: Chuck,
On 14 5 2015, at 2:22 am, Chuck Hill <ch...@gevityinc.com<mailto:ch...@gevityinc.com>> wrote: FrontBase will "return" the sequence number if the transaction is rolled back, but I am pretty sure that EOF does a commit immediately after selecting for a PK. It is possible that somehow the commit after the PK select failed and the exception got eaten, I suppose. That seems a bit far fetched. Hmmm.... here I might possibly see a way to prevent the problem in future: correct me please if I am wrong, but I understand permanentGlobalID causes this generation (and commit), right? IIRC, the generation and commit are from EOF. permanentGlobalID calls into that code to get the ID. Well then, what if I, at the moment any EO gets inserted into an EC, immediatelly called permanentGlobalID for it? The original problem was caused, as best I can call, by FrontBase vending the same sequence number twice. Doing what you describe won't change or avoid that underlying problem. It will just change when it happens. Chuck Unless I am overlooking something, it should get, commit and assign a safe PK for the EO. Later, when the EO gets saved, no PK clash would be possible. About the only drawback I can see is that when generating lots of new EOs, there would be many unnecessary roundtrips to the DB and it would be sloow. But normally I create at worst tens (normally just a couple) of EOs inside a r/r loop, and batch imports etc. need to be optimised separately anyway. Might this be a solution? Or am I overlooking something of importance, as so often? Thanks a lot, OC
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
