I have a Duplicate button in a table row that calls DuplicateRows(thisRow) and adjusts some values in the new row. The table is referenced by other tables. In some of the child tables, when the row in the parent table is duplicated by DuplicateRows(thisRow), the rows in the child table are updated to point to new parent row. In some, they are not (which is the desired behavior – duplicating the parent should not change the children).
Concrete example:
Parent table: Artwork
Child tables: Time Tracking, Artwork Cost
Each Artwork row has zero to many related Time Tracking rows and zero to many related Artwork Cost rows.
A row in Artwork has the title “Blue Bowl”. When I call DuplicateRows(thisRow) from that record in the Artwork table, the rows that pointed to the original “Blue Bowl” in the Time Tracking table are changed to point to the new Artwork row. This is bad. Rows in the Artwork Cost table that were related to the original “Blue Bowl” Artwork row remain unchanged.
The Artwork table has a Whole Lot of Fields, so I do not want to write a formula that calls AddRow() and then manually sets the value of each field. I will inevitably forget to amend the formula when I add more fields.
How can I prevent DuplicateRows() from stealing child table rows? Why on earth does it happen with some child tables, but not others?
1 Like
In case anyone else runs into the same bug, here is how I’m working around it. After calling DuplicateRows(), find rows pointing to the new row copy in other tables, and point them back at the row I duplicated. Ridiculous, but it works.
RunActions(
DuplicateRows(thisRow),
ModifyRows([DB Time Tracking].filter(Artwork = thisTable.Last()), Artwork, thisRow),
ModifyRows(
[DB Income].filter([DB Artwork] = thisTable.Last()), [DB Artwork], thisRow
)
)
1 Like
you are using the correct solution.
the DuplicateRows() is working as expected, it duplicates all the columns with the same values as the original row.
then you can make whatever changes you wish using modifyRows().
Hello @Janice_Cat ,
Although I usually agree with @Agile_Dynamics , I think we need to look a little closer at your code and the way the relations are setup.
If your relations from the child to the parent table are related to the display column in the parent table, you should not have to add the extra lines of code to reset the relations - I do similar things all the time and I never reset my relation.
Looking at the attached code snippet, I see you are filtering on two different columns (fields), namely “Artwork” and “DB artwork”. If your relations are setup to anything but the display column, you will run into the problems as you describe them.
Specifically, you are saying “Why on earth does it happen with some child tables, but not others?”: that behavior is consistent with what I am saying above (different relation columns).
Maybe I am wrong, but it would be my guess this can be solved by setting the proper relations.
Greetings,
Joost
2 Likes
ah… well spotted @joost_mineur
you are quite correct in your diagnosis i believe
1 Like
Hi @joost_mineur ,
All of my relationships are to the display column. I used Scott’s database diagram pack ( Database Diagram Pack, extend Coda with Database... - Coda ) to create a database diagram to verify that.
My naming conventions evolved as I created the doc, so sometimes the pointer to the [DB Artwork] table from another table is called [DB Artwork] and sometimes it’s called [Artwork]. The code snippet is just finding the rows in [DB Time Tracking] and [DB Income] that are related to the new duplicate row in [DB Artwork] and pointing them back to the row that I duplicated. There are six tables with pointers to [DB Artwork]. Four of them are handled properly by calling DuplicateRows() on a [DB Artwork] row (which is to say, nothing happens), and two are mishandled (their pointer to [DB Artwork] is changed to point to the new duplicate row). Those are the two that you see me referencing in the code snippet to clean up the mess that DuplicateRows() made.
What specifically about the code snippet makes you wonder if the relationship configuration is at fault? I’m wondering if your observation can point me down a new avenue of investigation.
1 Like
Hello @Janice_Cat ,
I would love to answer your question, but all you are sharing is a code snippet. I still think my answer is correct, but I can’t spend the time needed to reverse engineer your doc and help you any further. Make a dummy doc and share that with us so we can check what is going on.
Greetings,
Joost
2 Likes