So I have 11 fields available to enter a contractors name into on my Adding Data layout,
A better approach is to have 11 records, one record for each contractor. It makes reporting much simpler in most cases and you are no longer limited to a maximum of 11 contractors when you use records instead of fields.
And looping through records is a lot simpler than looping through fields.
agreed looping through records is a lot better than fields but the idea is that these are for contractors and not full time employees so they change on a daily basis. Having a record that will allow me to enter their names in once and generate a new record for each name would work best for my situation. Thanks for the fast response.
but the idea is that these are for contractors and not full time employees so they change on a daily basis.
Sorry but I see no advantages for you in using a set of fields with one field for each contractor instead of a set of records with one record for each contractor. These can be displayed in a layout as a set of list view records or in a portal. The data entry task becomes much the same, but the script, and the data becomes much easier to work with.
As far as for reports, it will end up looking the same because in the end, you have a record for each contractor but the whole point is so I can say
these 5 contractors worked from 7am to 5pm on this date at this location but only have to update one record, instead of 5
Phil is giving you excellent advice regarding the advantage of records over fields. You can hardly expect to request & receive specifically non-optimal solutions. Imagine this: instead of 11 fields, you simply have one portal. To enter a new contractor, you simply go to the last row and enter the new contractor & his or her hours. Or, if you've already used this contractor- select him/her from a list. Done. Contractors and hours are associated by being on the same record. For individual layouts- no need to copy or paste anything anymore.
If you want run a looping script (to, say, set all the starting times on all the contractors to be 9am), with a portal you simply make the last instruction in the loop- go to next portal row & if it's the last, exit loop. Done. You're using filemaker like a spreadsheet, but if you take the time to learn to use it as a relational database, you will be much better off.
Your situtation is like *the* classic example of how relational databases are an excellent alternative to listing fields. Just because a person is a 'record' in your database doesn't make them a 'part' of your organization.
Anyways, that's the basic idea. Phil will no doubt be able to offer a more optimal solution for you as he has for me on many occasions.
You may find it enlightening to look at this thread where different circumstances require looping through fields in the same record. Note some of the complexities involved in getting that to work: Problems displaying 1 to 1 fields on a layout
I guess taking a step back and looking at this as a database rather than a spreadsheet has really helped to take this project back to the drawing board. Thanks for the suggestions guys and I'll post later when I get something going. Thanks again everybody