Would it be prudent to have a development pallet like layout to copy and past fields from or is there a better way?
That's a very good way to do this. This can also help you standardize field height, text format, etc.
Im using a number of records that consist of only global fields to control a number of things and was wondering what challenges I might run into if I used these records as my primary layout record?
How's that again? If the fields are all global, then every record in the table will display the same data on every record. You don't need any records in a table if all the fields have global storage specified.
I tend to have a number of relationships to values in these "global tables" I also use them for work records to standardize the data input stored elsewhere in the database/solution (such as odbc linked tables) they let me do quite a number of things. I tend to use them alot to store environment and user data that enable a number of custom security features ( these features are extensions of the native security that I am able to pass along to users to administrate without opening up Filemaker's native security.)
Yes, but you said "I'm using a number of records". Multiple records of the same table where all fields are global are all going to show exactly the same data all the time.
I do find it useful to put all global fields that aren't used as keys in a relationship in a single table. It makes them easier to keep track of and they can still be accessed from any layout and from any script in my solution. (no relationship between tables is required to access global data as long as it is defined in a table of the same file.)
Im used to the terminology of a record being the equivelent of a table. I should have said tables. I can see the misunderstanding.
A FM record would be a row. Ill try to remeber that its a confusing terminology difference