Aren't you violating the uniqueness constraint on the primary key? Does insertRow() return true? What about submitAll()?
Aren't you violating the uniqueness constraint on the primary key? Does insertRow() return true? What about submitAll()?
Well, I tried the submitALL() and nothing happened but let me come back to that. Yep, insertRow() returns true -- just for fun, I changed line 66 to set the data to "old_fp_id" and I was able to effectively double the data saved with the dataset I'm copying. Row 1 was copied to a row 3, and row 2 copied to row 4 and off I went on my merry way.
As for the primary key, what's happening is I select on a row in my master view (call it SNOW), say COPY, and that prompts me for the name of a new master row (call it RAIN -- this is the primary key), so that's covered. I then want to copy the detail rows linked to SNOW and link those new ones to RAIN which is what you see on line #66 of the first block of code.
You gave me an idea about the primary key, though. My creation of *new* master and detail records (vs. copy) works great EXCEPT for something I just discovered. I have to submitALL() after the creation of the master record - if I don't and I try to create detail records, a submitALL() at this point results in no detail records being saved. Even though I'm not getting a DB error on my submitALL(), since I don't know the order that the records are being written out, there could be an issue where the child records can't get created in the DB correctly because the parent/primary key record doesn't exist yet.
When I leave my normal job I'm going to try a submitALL after line 14 of the first block of code (which is where the new master record is being created) and see if that helps...That should write out my new master/parent record...
Thanks for the questions -- they pulled me up out of the weeds! (BTW -- my day job is as an Oracle DB programmer so you'd think this would be a cakewalk)
scott
Bookmarks