Generate Custom Number and assign to another field on the form
I am generating a custom record number based on three fields:
Type
SO#
WOID
The custom number is created using the following equation:
= [SO#] & Left([Type],1) & [WOID]
I first used this equation as the source for the WorkOrderNumber field and the custom number was not saved in the field in the table.
So I then created an unbound field to capture the custom number and then I set the WorkOrderNumber field equal to the unbound field.
Neither saves the the custom number and I would like to save this number since it should not change once assigned.
Thoughts?
Type
SO#
WOID
The custom number is created using the following equation:
= [SO#] & Left([Type],1) & [WOID]
I first used this equation as the source for the WorkOrderNumber field and the custom number was not saved in the field in the table.
So I then created an unbound field to capture the custom number and then I set the WorkOrderNumber field equal to the unbound field.
Neither saves the the custom number and I would like to save this number since it should not change once assigned.
Thoughts?
pdebaets
Use a query based on the table instead of the table for your form recordsource. Create a field in the query that concatenates the 3 fields. Now you can use a bound text box to display the custom number.
Peter has pointed you in the right direction, but to expand:
You should not save values like that in a table. Instead, since you always have the "root" values available (i.e. the Type, SO#, and WOID fields) just "build up" that value when you need it. The only reason for that value is for human readability, and you can run into troubles down the road if you stored "calculated" values like this. For example, what if the Type changes? You'd have to be sure that you also update that calculated value, and if the user somehow gets to the table and changes it directly, your data becomes flawed.
So save the "root" values, and use a query as Peter suggests.
You should not save values like that in a table. Instead, since you always have the "root" values available (i.e. the Type, SO#, and WOID fields) just "build up" that value when you need it. The only reason for that value is for human readability, and you can run into troubles down the road if you stored "calculated" values like this. For example, what if the Type changes? You'd have to be sure that you also update that calculated value, and if the user somehow gets to the table and changes it directly, your data becomes flawed.
So save the "root" values, and use a query as Peter suggests.
ASKER
But, if someone mistakenly changes the SO# or the type, then the number will change and I would rather not have to lock down the fields.
then the number will changeThe number would not change unless you put code in place to insure it changes. That's the entire concept behind NOT storing calculated values, and instead storing the root values - changes made to the "root" values would be reflected in your forms and reports and queries without you having to do anything further. If you stored the full calculated value, you'd have to insure you make the required data changes in all those locations to insure you write back the calculated value correctly.
I would rather not have to lock down the fields.I'm not sure what you mean by this, but you don't have to lock down anything (and you can't do that in Access anyway).
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
The Work Order number is a number that we need to set once. It does not change for the duration of the work order and for the most part the only time that the other parts may change is due to an entry error.
I will just use the calculated field.
I will just use the calculated field.
for the most part the only time that the other parts may change is due to an entry error.I've been doing this a long time, as has Pat, and my experience has always been that forcing non-standard behavior (like this) is never a good idea.
But it's your data, and you're the one who'll have to deal with the mess ...
Also, you really should not have accepted my comment as your "solution". Pat's answer will provide you with the method to store your calculated value, so I've asked the Moderators to change the award.
Thanks Scott.
ASKER
OK,