Copy this row and edit current row and all relevant children

[RLCDProperties]

I’m creating a MoveIn/MoveOut Inspection app, and would like it to work like this:

1. Create a Move In Inspection record, with the inspections from each room/area residing in its own table and referencing to the Move In inspection being created.
2. Upon Move Out, copy the corresponding Move In, including all of the applicable children rows from the other tables, change the row key values to new unique values and then be able to edit that new Move Out record and its children.

I’ve seen various questions sort of like this previously but no good answers and am hoping something has changed or I’ve missed something. It’s easy to copy and edit a single row, but I can’t figure out how to do the same with its children.

[Steve]

Not possible from the app itself.

[Lynn]

Hi @RLCDProperties Have you had a look at the sample Apps “Property Lease Manager” and “Move in Move out checklists” ?

[Phil]

Have you considered the following alternatives.

1. Each room record might contain both MoveIn fields and MoveOut fields. You would fill in the former fields during Move In, and the later fields during Move Out.

2. Another, and likely better, possibility is for each Room record to have a child MoveIn record and a child MoveOut record. All common room data would be stored in the Room record. MoveIn and MoveOut specific information would be stored in the child MoveIn and MoveOut records.

I suggest these alternatives because one of the most important principles of database design is to avoid replicating data. Every “fact” should be stored in exactly one place (i.e. one record). That way, if you need to update the “fact” later, you only need to make the change in exactly one record. If you replicate the same “fact” in two or more records, you need to update every replica of that “fact” to keep your data consistent.

We see lots of questions about making copies of data. Whenever you see a question like this, you should immediately ask why the design requires this. In the vast majority of cases, it is because the design is violating the important principle of keeping each “fact” in only one place.