If this were 80 records in a related table, simply sorting the records is all that you would need to do to identify the record with the smallest value.
A looping script could identify the field but why do it the hard way?
Phil hints at the question but I'll try to raise it in a slightly different way.
This sounds like a design problem.
It sounds like you should NOT have 80 fields that you need to search this way.
But should, instead have 80 related records.
Often a big clues is the names of the fields, where the names include a number.
Something like Color01, Color02, Color03, Thing1, Thing2, Thing3, etc.
In your case - what are the names of these fields?
Hi Bruce, you assume correctly and I understand that I am perhaps going about this the hard way. I was somewhat forced into this method by a number of factors. If there is no simple method of returning the field name I may have no option but to rework it. Trying not to do that
I suspect if you had decided to rework, it might be done by now.
Much better for all concerned to reinforce your normalization muscle-memory and get the design right.
If you don't want to rework your existing data structure you'll need to
jump through some hoops.
Create a layout that contains all of the fields that you want to look at.
Create a script that loops through all the fields, testing the value as
Get the field name using Get(ActiveFieldName)
I'm interested in what you will do once you know the name of the field containing the min value.
Visually, on a layout you can format all the 80 fields with the same formula, self = Min( f1; f2; ... f80) makes the fill color red and the text color white.
Thanks guys. After considering your responses I think the best course of action is to rework the database. Even though I might find a way around what I am trying to achieve now I will have the same problem with the next feature I attempt to add.