Welcome to SPN

Register and Join the most happening forum of Sikh community & intellectuals from around the world.

Sign Up Now!

Option Groups

Discussion in 'Information Technology' started by B.Young, Jul 28, 2006.

Tags:
  1. B.Young

    B.Young
    Expand Collapse
    Guest

    Here's what I've got. A checklist with 30 different points to check. Each
    point needs to have 3 options next to it. one for "Completed at arrival",
    one for "Fixed On-Site" and the third for "Primary TC reason". What I want
    to do is have people mark either one of the first two, which is no problem
    with basic option group set up, but I also want them to be able to mark if it
    was the tc cause, along with one of the other options. How would I do this?
    Do i set up the first two as one field and create an option group off of
    that, then have primary cause as a second field with a check box? or is
    there some way to have it all in one field? Am I totally confusing?
     
  2. Loading...

    Similar Threads Forum Date
    Adoption: Why is it Taboo? Hard Talk Jun 21, 2013
    USA Florida Court Voids Adoption Of Millionaire’s Girlfriend As Sham Breaking News Mar 29, 2013
    Opinion Dog loving babas of Juna Akhada advocate adoption of street dogs Breaking News Jan 21, 2013
    Controversial Only option for fading churches is to again take up evangelization Hard Talk Dec 26, 2012
    Introducing New Functionality: Dislikes Option Announcements Apr 12, 2012

  3. John Vinson

    John Vinson
    Expand Collapse
    Guest

    On Wed, 14 Jun 2006 18:41:02 -0700, B.Young
    <B.Young@discussions.microsoft.com> wrote:

    >Here's what I've got. A checklist with 30 different points to check. Each
    >point needs to have 3 options next to it. one for "Completed at arrival",
    >one for "Fixed On-Site" and the third for "Primary TC reason". What I want
    >to do is have people mark either one of the first two, which is no problem
    >with basic option group set up, but I also want them to be able to mark if it
    >was the tc cause, along with one of the other options. How would I do this?
    >Do i set up the first two as one field and create an option group off of
    >that, then have primary cause as a second field with a check box? or is
    >there some way to have it all in one field? Am I totally confusing?


    Yes. Very confusing. <g>

    It really sounds like you're starting your table design with the Form
    and the user interface. That's backwards; you need instead to create
    the Table or Tables with appropriate fieldtypes - THEN figure out how
    to manage data in these table.

    For a checklist, I'd suggest one ROW per checkpoint. You might want to
    have a thirty-row table: Checkpoints, with fields CheckpointNo
    (primary key, integer I'd suggest), Description, and then any other
    fields pertaining to that checkpoint as an entity. Then there would be
    a second table with a foreign key linking the table to whatever it is
    you're checkpointing; a CheckpointNo field linked to the Checkpoint
    table; and then whatever fields you need to record for that
    checkpoint.

    John W. Vinson[MVP]
     
  4. B.Young

    B.Young
    Expand Collapse
    Guest

    "John Vinson" wrote:

    > On Wed, 14 Jun 2006 18:41:02 -0700, B.Young
    > <B.Young@discussions.microsoft.com> wrote:
    >
    > >Here's what I've got. A checklist with 30 different points to check. Each
    > >point needs to have 3 options next to it. one for "Completed at arrival",
    > >one for "Fixed On-Site" and the third for "Primary TC reason". What I want
    > >to do is have people mark either one of the first two, which is no problem
    > >with basic option group set up, but I also want them to be able to mark if it
    > >was the tc cause, along with one of the other options. How would I do this?
    > >Do i set up the first two as one field and create an option group off of
    > >that, then have primary cause as a second field with a check box? or is
    > >there some way to have it all in one field? Am I totally confusing?

    >
    > Yes. Very confusing. <g>
    >
    > It really sounds like you're starting your table design with the Form
    > and the user interface. That's backwards; you need instead to create
    > the Table or Tables with appropriate fieldtypes - THEN figure out how
    > to manage data in these table.
    >
    > For a checklist, I'd suggest one ROW per checkpoint. You might want to
    > have a thirty-row table: Checkpoints, with fields CheckpointNo
    > (primary key, integer I'd suggest), Description, and then any other
    > fields pertaining to that checkpoint as an entity. Then there would be
    > a second table with a foreign key linking the table to whatever it is
    > you're checkpointing; a CheckpointNo field linked to the Checkpoint
    > table; and then whatever fields you need to record for that
    > checkpoint.
    >
    > John W. Vinson[MVP]


    Ok, I think I've got your point, but I'm a novice at this (obviously) so let
    me see if I get what you're saying.
    Have 1 separate table for each checkpoint set up with fields pertaining only
    to that checkpoint. Example: tblCheckpoint1, contains a primary key field in
    addition to these fields, "complete on Arrival", "Fixed on Site", and
    "Primary TC Reason"(all yes/no checkboxes). I then link all those fields to
    a seperate table which will show them all in one place? Couldn't I make a
    query that looks at the entries w/ matching keys in all the tables? Then
    build a form off of that query? Or am I putting the cart before the horse
    again?

    Another Idea I had was to create a "tblchecklist" table that contains fields
    like the following: Checkpoint1 (option group, one option-"Complete on
    Arrival", one option-"fixed on site" (people will select one of these or the
    other, never both)); Checkpoint1PrimaryCause (yes/no field); Checkpoint2;
    checkpoint2Primarycause; etc... however this table would end up having 60+
    fields, would that be too much information in one table?
    >
     
  5. John Vinson

    John Vinson
    Expand Collapse
    Guest

    On Thu, 15 Jun 2006 16:32:01 -0700, B.Young
    <BYoung@discussions.microsoft.com> wrote:

    >Ok, I think I've got your point, but I'm a novice at this (obviously) so let
    >me see if I get what you're saying.
    >Have 1 separate table for each checkpoint set up with fields pertaining only
    >to that checkpoint. Example: tblCheckpoint1, contains a primary key field in
    >addition to these fields, "complete on Arrival", "Fixed on Site", and
    >"Primary TC Reason"(all yes/no checkboxes).


    NO. Sorry. That's even *worse*.

    Storing data in tablenames is *not* the right design, nor is storing
    data in fieldnames. You store data *in the table*, not in the
    structure of the table!

    >I then link all those fields to
    >a seperate table which will show them all in one place? Couldn't I make a
    >query that looks at the entries w/ matching keys in all the tables? Then
    >build a form off of that query? Or am I putting the cart before the horse
    >again?


    Read it again:

    For a checklist, I'd suggest one ROW per checkpoint. You might want to
    have a thirty-row table: Checkpoints, with fields CheckpointNo
    (primary key, integer I'd suggest), Description, and then any other
    fields pertaining to that checkpoint as an entity. Then there would be
    a second table with a foreign key linking the table to whatever it is
    you're checkpointing; a CheckpointNo field linked to the Checkpoint
    table; and then whatever fields you need to record for that
    checkpoint.

    You need TWO TABLES.

    One table with thirty rows, one row for each kind of checkpoing that
    you're going to need.

    Another table with thirty rows times however many whatsises you're
    checkpointing. Each row will have fields such as

    ObjectID
    CheckpointID
    CompleteOnArrival
    FixedOnSite
    PrimaryTCReason

    or, probably better,

    ObjectID
    CheckpointID
    Outcome <integer>

    You'ld use an Option Group bound to Outcome to store 1 for Complete on
    Arrival, 2 for Fixed on Site, 3 for Primary TC Reason.

    >Another Idea I had was to create a "tblchecklist" table that contains fields
    >like the following: Checkpoint1 (option group, one option-"Complete on
    >Arrival", one option-"fixed on site" (people will select one of these or the
    >other, never both)); Checkpoint1PrimaryCause (yes/no field); Checkpoint2;
    >checkpoint2Primarycause; etc... however this table would end up having 60+
    >fields, would that be too much information in one table?


    Yes, it would.

    Again: DO NOT STORE DATA IN FIELDNAMES.

    "Records are cheap, fields are expensive".

    You're apparently still using spreadsheet thinking - I understand that
    thinking relationally, and using tall-skinny tables, does not come
    easily - but it will be well worth the effort once you do!

    John W. Vinson[MVP]
     
  6. B.Young

    B.Young
    Expand Collapse
    Guest

    "John Vinson" wrote:

    > On Thu, 15 Jun 2006 16:32:01 -0700, B.Young
    > <BYoung@discussions.microsoft.com> wrote:
    >
    > >Ok, I think I've got your point, but I'm a novice at this (obviously) so let
    > >me see if I get what you're saying.
    > >Have 1 separate table for each checkpoint set up with fields pertaining only
    > >to that checkpoint. Example: tblCheckpoint1, contains a primary key field in
    > >addition to these fields, "complete on Arrival", "Fixed on Site", and
    > >"Primary TC Reason"(all yes/no checkboxes).

    >
    > NO. Sorry. That's even *worse*.
    >
    > Storing data in tablenames is *not* the right design, nor is storing
    > data in fieldnames. You store data *in the table*, not in the
    > structure of the table!
    >
    > >I then link all those fields to
    > >a seperate table which will show them all in one place? Couldn't I make a
    > >query that looks at the entries w/ matching keys in all the tables? Then
    > >build a form off of that query? Or am I putting the cart before the horse
    > >again?

    >
    > Read it again:
    >
    > For a checklist, I'd suggest one ROW per checkpoint. You might want to
    > have a thirty-row table: Checkpoints, with fields CheckpointNo
    > (primary key, integer I'd suggest), Description, and then any other
    > fields pertaining to that checkpoint as an entity. Then there would be
    > a second table with a foreign key linking the table to whatever it is
    > you're checkpointing; a CheckpointNo field linked to the Checkpoint
    > table; and then whatever fields you need to record for that
    > checkpoint.
    >
    > You need TWO TABLES.
    >
    > One table with thirty rows, one row for each kind of checkpoing that
    > you're going to need.
    >
    > Another table with thirty rows times however many whatsises you're
    > checkpointing. Each row will have fields such as
    >
    > ObjectID
    > CheckpointID
    > CompleteOnArrival
    > FixedOnSite
    > PrimaryTCReason
    >
    > or, probably better,
    >
    > ObjectID
    > CheckpointID
    > Outcome <integer>
    >
    > You'ld use an Option Group bound to Outcome to store 1 for Complete on
    > Arrival, 2 for Fixed on Site, 3 for Primary TC Reason.
    >
    > >Another Idea I had was to create a "tblchecklist" table that contains fields
    > >like the following: Checkpoint1 (option group, one option-"Complete on
    > >Arrival", one option-"fixed on site" (people will select one of these or the
    > >other, never both)); Checkpoint1PrimaryCause (yes/no field); Checkpoint2;
    > >checkpoint2Primarycause; etc... however this table would end up having 60+
    > >fields, would that be too much information in one table?

    >
    > Yes, it would.
    >
    > Again: DO NOT STORE DATA IN FIELDNAMES.
    >
    > "Records are cheap, fields are expensive".
    >
    > You're apparently still using spreadsheet thinking - I understand that
    > thinking relationally, and using tall-skinny tables, does not come
    > easily - but it will be well worth the effort once you do!
    >
    > John W. Vinson[MVP]
    >
    > Ok, I think I know where you're going, I'm still in the phase of trying to figure out what I want in the database. When I get some tables thought up I'll probably ask you to give me some input. Thank you for your help and being patient with my misunderstanding.
     

Share This Page