I'm creating a database for a group that has ever changing reporting requirements based on the values of a few different fields. I want the default requirements to be set as a new record is created, but then the user should have the option to change those requirements. My current plan is to use a categories and an items database in the following way:

1 -- Include in the Categories database one field for each possible requirement. Each category will have a binary value for each requirement, designating whether the requirement is a default for that category.

2 -- In the item database, various information will be entered, followed by a "Choose Category" value list and a "Set" button. The value list will be based on the category names in the Categories database, and the go button will call a script that will run a set value for the requirement fields, which will be duplicated in the Items database.

3 -- The user will then be passed to a "Requirements" layout which will allow them to edit the values that were set by the script.

For some reason (I wonder why) I feel like I'm overcomplicating this process, but nothing else is coming to mind. It is important to have the ability to edit the current default requirements for the categories, which is why I've put them into a database of binaries.

The solution has to be Windows compatible, so I can't use any AppleScript functions.

Thanks in advance!

Use the "Auto Enter" by data or calcualtion function. When a new record is created the data you specify or calculation you specify will be executed and the field will be populated with the results(your current defualt value). You can access it by clicking the options button in the Define Fields Dialog. Be sure that "Prohibit modification of value" is unchecked so your users can edit the data.

Thanks for the reply. Part of my problem is that the default values being applied have to be editable by the end users. So they'd have to be able to go in (frequently) and change the defaults or create new ones. I don't think it'd be safe building these defaults into the creation script, since the users would have to edit my script to change the values.

This was my reason for having the defaults for each category stored in a database and only referenced at the time of record creation. Is there any way to script a lookup at the time of creation (the items database will be related to the categories database on the category match field)? That would at least save me from having to do all of those Set Field steps.

Since you want the fields to have default values, and you want the users to be able to edit these default values, store the default values in global fields and set the data fields to auto enter a calculation that is set to the appropriate global field.

Chuck

To complete that, all it would take is a managerial layout including all of the global fields, correct?

Excellent suggestion, I'll give it a try.

The only thing to watch out for in the use of globals for default values is that these presets can only be changed when the database is single user. In a multiuser environment (on server) where it is not convenient to take the database down to change presets, it is better to user a separate file with standard fields and one record. -bd

Make a new with file with one record to hold just your settings. Then use an auto enter calc to enter the values through a relationship. That way anytime you need to change the values just open the related file and make the changes.

G

The only problem I can think of, and on reflection this applies to the global fields solution as well, is that the categories database (which is intended to hold all of the default requirements) will have several categories, each with its own set of defaults.

Where one requirement may be a default of $500 for one category, it could be $250 or not required for another. My intent was to have a record for each category, a field for each requirement, and the default for each category in the appopriate field. What concerns me is that the creation script, in setting the values of some 20 fields in the new Items record, will be a hefty performance hit, since each set value will be accessing the related Categories record.

Thanks again for all of the input, folks. I'm at least getting the feeling that this has been thought through!