Results 1 to 3 of 3
  1. #1
    cap.zadi is offline Competent Performer
    Windows XP Access 2007
    Join Date
    May 2011
    Location
    KSA
    Posts
    481

    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

  2. #2
    cap.zadi is offline Competent Performer
    Windows XP Access 2007
    Join Date
    May 2011
    Location
    KSA
    Posts
    481
    hey there, still waiting for help?

  3. #3
    dblife's Avatar
    dblife is offline Advanced Beginner
    Windows XP Access 2003
    Join Date
    Nov 2011
    Location
    South Shields, UK
    Posts
    95
    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.

Please reply to this thread with any new information or opinions.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Other Forums: Microsoft Office Forums