Yes, that is the intention. Labels are not guaranteed to be unambiguous, while column labels are, and on import when matching names column names are given higher priority than labels.

Separately, eventually "export to excel" should have an option to choose whether to use labels or column names (field keys?)

hi matt,

i get where you're coming form, but i really think you should re-consider that. the whole point of labels vs names is that the former is what the user is presented with. in a dataregion, import panel, etc, labkey presents the label, not the name. what's the rationale for making the excel template any different?

i fully agree that the code parsing the excel header should preferentially use the name; however, seems like both ought to work.

second, does labkey really allow redundant labels on columns within a table? that seems unwise if true.

Unfortunately, labels really aren't unique. It's pretty common to not be able to import the Excel files that we export. Never fun when that happens. If we make a name/label option on export we could do the same for templates.

is there a reason we dont enforce labels to be unique in the table definition?

i get that aliases arent unique, but label seems like an extention of name.

A large amount of the source data that gets imported into LabKey has duplicate labels. Users distinguish the ambiguities positionally (e.g., groups of columns that get repeated) or based on datatype (e.g., measurement column follow by unit column... both with the same label). It's unfortunate, but we have to tolerate this.

so do these scenarios use the browser spreadsheet import or do they use other pathways like ETLs, pipeline imports or API?

I think an option on export would clue in the user that there is a difference. If I were a non-tech user, I would have given up and brute forced my changes into the table. Not only do the fields and columns have to agree but the content may need to be changed. e.g. an export of our lab reference ranges lookup table replaces a gender code with the person friendly "male" / "female". The import doesn't know what to do with "male" so it leaves it blank.