D
Deleted member 147267
Guest
Then you have at least 2 entities - Coils and Processing. A coil is a unique thing, even if it completely resembles another in all physical characteristics - same as people when they are twins. Serial numbers would be a unique index, all necessary data pertaining to the coil in other fields.
Processing (or whatever you want to call it) is an instance where the coil is fed into the mill. If that is the 2nd time, the coil ID is pulled from data because this eliminates typos when it gets reloaded and you now have 2 (or more) processing records for that serial. IMO the time to enter the coil as an entity is when it is received, but if that's not feasible there is still a better approach IMO. It goes against normal practice to be creating records on the 'many' side of a relationship and worrying about the 'one' side later. Even if I didn't want to enforce logging a coil when received, I'd make it requisite to enter the 'one' side value first before allowing the creation of records on the many side at the moment it's in the mill and you've stepped up to the podium. In such a design, you can then do away with free form serial entry when you might be dealing with a serial that is already in a record. That's where the FAYT or listbox suggestion was coming from.
So in one simple scenario,
you step up to the podium, enter the serial in an unbound textbox and press 'find'
not found? Prompt to add
add if Yes, then requery the main and subform (which you don't have but would show multiple mill loads if you did)
or it was found, so load the form(s) with records for that serial.
OR
just have a find form. Enter the serial,
if not found, prompt to add, if yes, open the form(s) blank but enter that serial in the form control
if found, open the form loaded with that record.
Click Add New, unhide the search form, rinse and repeat
I think I'd prefer everything on the one form, but doing so would make it more complicated for you (maybe) in terms of reloading forms. A simple requery won't work as it will take you to the first record when what you'd want is to use the Bookmark property or FindRecord method.
Processing (or whatever you want to call it) is an instance where the coil is fed into the mill. If that is the 2nd time, the coil ID is pulled from data because this eliminates typos when it gets reloaded and you now have 2 (or more) processing records for that serial. IMO the time to enter the coil as an entity is when it is received, but if that's not feasible there is still a better approach IMO. It goes against normal practice to be creating records on the 'many' side of a relationship and worrying about the 'one' side later. Even if I didn't want to enforce logging a coil when received, I'd make it requisite to enter the 'one' side value first before allowing the creation of records on the many side at the moment it's in the mill and you've stepped up to the podium. In such a design, you can then do away with free form serial entry when you might be dealing with a serial that is already in a record. That's where the FAYT or listbox suggestion was coming from.
So in one simple scenario,
you step up to the podium, enter the serial in an unbound textbox and press 'find'
not found? Prompt to add
add if Yes, then requery the main and subform (which you don't have but would show multiple mill loads if you did)
or it was found, so load the form(s) with records for that serial.
OR
just have a find form. Enter the serial,
if not found, prompt to add, if yes, open the form(s) blank but enter that serial in the form control
if found, open the form loaded with that record.
Click Add New, unhide the search form, rinse and repeat
I think I'd prefer everything on the one form, but doing so would make it more complicated for you (maybe) in terms of reloading forms. A simple requery won't work as it will take you to the first record when what you'd want is to use the Bookmark property or FindRecord method.