Hierarchy and Refs

[Scott_Hall]

Still fighting with the app. I’m so close yet I feel like I don’t have the ref structure down correctly. My primary concern is using “company” and “service location name” as my key due to the risk of duplicates. Yet when I look at sample apps they seem to use “name” as a key which seems dangerous to me. Can you please recommend a best practice for the key, label and ref structure for the following tables.

Table “Company”
Child Table “Service Location”
Child to Service Location is “Service Location Repair”

A Company can have several “Service Location” and a “Service Location” will have dozens of “Service Location Repair”

At this time each table has a UNIQUEID() as key and refs the higher table as the label.

What would be the recommended key and label and ref structure for this setup?

[Steve]

I recommend against using a value that could change over the lifetime of the app (e.g., a name, address, phone number, email) as a key value. I recommend using a UNIQUEID() key value unless there is a specific, compelling need to use something else. If you then want to avoid duplicate non-key values, you’ll need to ensure you have good Valid If expressions in place.

[Scott_Hall]

Thanks @Steve So will the key, label and ref structure I described allow me to schedule reports with information from all three levels? Ie. Company, Service Location Name, Service Location Repair Details in a log report?

The source table “service location repairs” yields just the related key values. But from a log/ records standpoint it is necessary for me to be able to print a document that contains the company name, their service location name and the service location repair details. Can reports accomplish this with the key, label and ref structure I described? It reports can accomplish this, then I’m good. Just have to figure reports out.

[Steve]

I’m confident you’ll be able to produce a report with the desired information.