On 28.02.2014, at 20:17, Calven Eggert <cegg...@uhnresearch.ca> wrote:
> FYI, the problem has been solved (on initial testing) by checking the > "Propagates Primary Key" checkbox for the relationship between table A & B. > The ID is now using the proper sequence number. The sequence number for > table A is very close to the sequence number for table B. > This bothers me. Why would you want to propagate a primary key in this scenario? My guess is that you have an inconsistency in your EOModel. WO is usually clever enough to handle your scenario. It will start a transaction against the dB, read nextval for the A record and then several times nextval for the B records. This should ensure that the sequence values are (more or less) contiguous. I never experienced your problems - and I never had to propagate the PK (you would do this on a 1:1c relationship, but not on a 1:n). Check your model. Any PK exposed? Any other inconsistency in the relationship? Have fun ---markus--- > > On 2014-02-28, at 12:32 PM, Chuck Hill wrote: > >> Jumping 40 from 37427 to 37467 is a little suspicious. Is there an >> increment > 1 on this sequence? It could be that EOF has a cached value out >> of sync with the database. >> >> Or is the database sequence out of sync with the data in the table? Try >> re-creating the sequence. >> >> Is anything else writing to this database besides EOF? >> >> Chuck >> >> >> On 2014-02-28, 6:07 AM, "Calven Eggert" wrote: >> >> I have a table A that has a one to many relationship to table B. (A->>B) At >> the time A is created a user may choose to create multiple B records before >> they all get saved. >> >> Problem is that the B records are causing a "unique constraint" error. The >> first sequence number is always an already chosen ID in the table. >> >> Here is a snippet of the code generated: >> >> SELECT JOBS_NOTES_SEQ.NEXTVAL FROM DUAL >> SELECT JOBS_NOTES_SEQ.NEXTVAL FROM DUAL >> >> INSERT INTO JOBS_NOTES(NOTES_SUBMITTED_BY, NOTES_HYPERLINK, >> NOTES_USER_VISIBLE, NOTES_JOB_ID, NOTES_SUBMITTED_DATE, NOTES_DESCRIPTION, >> NOTES_ID, NOTES_ATTACHMENT_NAME) VALUES (?, NULL, ?, ?, ?, ?, ?, >> ?)1:204(submittedby), 2:"Y"(uservisible), 3:14456(jobid), 4:2014-02-27 >> 13:34:27(submitteddate), 5:"2"(notesdescription), 6:37427(notesid), 7:"eyetv >> serial number.rtf"(attachmentname)>: >> INSERT INTO JOBS_NOTES(NOTES_SUBMITTED_BY, NOTES_HYPERLINK, >> NOTES_USER_VISIBLE, NOTES_JOB_ID, NOTES_SUBMITTED_DATE, NOTES_DESCRIPTION, >> NOTES_ID, NOTES_ATTACHMENT_NAME) VALUES (?, NULL, ?, ?, ?, ?, ?, >> ?)1:204(submittedby), 2:"Y"(uservisible), 3:14456(jobid), 4:2014-02-27 >> 13:34:27(submitteddate), 5:"2"(notesdescription), 6:37467(notesid), 7:"eyetv >> serial number.rtf"(attachmentname)>: >> >> Next exception:SQL State:23000 -- error code: 1 -- msg: ORA-00001: unique >> constraint (CRE_MASTER.SYS_C001646) violated >> >> The number 37467 is correct but the first number 37427 is not because it is >> an already existing primary key. huh? >> >> Anyone have any suggestions? Why is the first number invalid and why is the >> second one valid? >> >> Calven >> >> > > _______________________________________________ > 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/mailinglists%40kataputt.com > > This email sent to mailingli...@kataputt.com
_______________________________________________ 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
