-
Is right way to do?
Hey there, i need to have a database which can perform the following data inputs.
i have a workstation where i recieved the KilnCars from a Kiln for Unloading and have made following objects (sample database is attached):
tblSortingInfo
PK TrnNo AutoNumber
SortingDate
ShiftID cbo: Value List
FK MachineID cbo: frm tblMachinesInfo
FK EmpID cbo: frm tblEmpInfo
tblSResultsInfo
PK ResultNo AutoNumber
FK TrnNo frm TblSortingInfo
FK KilnID frm tblKilnInfo *Can it be Value List.
TimeStart
KCarNo
GoodQty
RejectQty
FCuttingQty
*if there is 20 Pc's of Product is rejected "RejectQty" so must have the some reasons for those rejects:
RejectReason
-5 = Clay Crack
-15 = Long Crack
Same step is required for "FCuttingQty" field where can be used same reason codes like "Clay Crack, Long Crack".
So please advise here how to manage this 3rd relationship with the "TblSResultsInfo"
*When ever eneter data in the fields "RejectQty" or FCuttinQty" so must have a new form which can allow to enter the partical Qty + Reason.
* Is those EmpInfo and machinesinfo tables are correctly designed?
* How can be flexible if i have some more workstations with different data inputs and keeping concern supporting info frm "tblEmpInfo" and t"blMachinesInfo".
the sample database is attached for your kind review.
thanks
zee
-
hey there, still waiting for help?
-
The thrid table for allowing explanation of the defects could be done using extra fields but I imagine it would be best to have it as a table in itself.
I do not fully understand your notation please adapt what I have put below.
tProductionRun
prID
prRunDate
prTargetFigure
tProductStatus (table to record what category a produced part falls into eg. good, reject, rework etc)
psID
psDescription
tRecordOfGoodAndBadProductsInEachRun
rogbID
rogbProductionRunId [fk from tProductionRun]
rogbNumberOfParts
rogbPartStatus [fk from status]
rogbComment
This 'relational' approach will allow greater flexibility - you can have as many defect descriptions as you like. And as many defect types per production run as you like.
As for the second part of your question, are the data inputs or tables ok?
I might say you seem to want to use 'cbo' in a table which I think may be a look up. Usually frowned upon by the people who do this for a living.
Combo's are for forms - tables should be as basic as possible.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules