Results 1 to 7 of 7
  1. #1
    Join Date
    Dec 2005
    Posts
    11

    Red face Unanswered: Tips on Voting application

    Hi Guys,

    Im making a Voting Application and am relatively new to Access.

    Wondering if anyone has tips on the following:

    Code behind a command button,where new users/voters to the system can register their details,which can then be stored in a "Voters Table" named tblVoters under headings/Keys Firstname and Secondname.

    This might help:
    The opening form is called "frmLogin"

    The new user enters their first and second names in textboxes called "txtFirst" and "txtSecond" respectively.

    My login Command Button is called "cmdLogin"
    Then the aim is to have the Voters details recorded in tblVoters!

    Thanks.

  2. #2
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    What happens if you have two voters named Bob Johnson?

    In general, primary keys should have no significant meaning to you or the user what-so-ever.

    Start here. If you can get your head around that, you'll be in good shape.
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  3. #3
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Quote Originally Posted by Teddy
    Start here. If you can get your head around that, you'll be in good shape.
    Lol - good old Rudy & Letwin - third link to that page today (1 and 2).

    <ot> BTW - teddy - I know you are a strong advocate on using surrogate keys - in principle I agree however I felt forced to use composite natural keys after considering surrogate keys in a recent application. Do you have a decent reference or article you could point me too (ideally not Google if you please - I've searched around but found nothing genuinely in depth and thorough). Appreciated as ever. </ot>
    Last edited by pootle flump; 12-07-05 at 16:14.
    Testimonial:
    pootle flump
    ur codings are working excelent.

  4. #4
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    What were the circumstances for the composite keys?
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  5. #5
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Quote Originally Posted by Teddy
    What were the circumstances for the composite keys?
    Hi Teddy
    Started a new thread but to answer this but I found I had big gaps in my memory for the design. I will dig it out at work tomorrow if necessary. The gist was - it wasn't really an app but some bolt on in house functionailty to a third party db however I modelled it from the ground up to investigate using surrogate keys. I abandoned them simply because, by the time I had reached third form, it took a query including about a dozen tables to answer the single business requirement. I can totally appreciate the purity of a surrogate key - keep your business knowledge away from the PK of a table - however the "deeper" a table is in the relational design, the more tables you need to include to actually provide any business knowledge. And it tends to be these "deep" tables that most of your querying is based on. The achilles heel of natural keys (business knowledge is used to hold the application together) is also its strength - no need to include x, y and z master tables to provide meaning to the data.

    I know I haven't answered your question as such. I will see if I can dig out or reformulate the ERD if you like
    Testimonial:
    pootle flump
    ur codings are working excelent.

  6. #6
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    Sounds like about what I expected.

    I resorted to temporary surrogate keys once to import data from a third party administrator (TPA). My client received claims information (insurance) from a third party on a monthly basis. For whatever reason, the TPA refused to include policy numbers as part of their export. I had to rely on a composite of company name and and "doing business as" name to pull the information back into the database.

    That particular instance also had a few issues which illustrate why composite meaningful keys can be an issue. The TPA data entry goons were not paid enough to keep track of miskeys. They were also notorious for abbreviating anything more than five letters long that wasn't a proper name... you know.. to save a few seconds of payroll. Naturally this caused amusing discrepencies between their records and ours.

    Hence the "in general" preface to my "keys should have no meaning" post. There are a few scenarios where composite keys with significant meaning are the only sensible option, but they are few and far between.
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  7. #7
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Quote Originally Posted by Teddy
    Hence the "in general" preface to my "keys should have no meaning" post. There are a few scenarios where composite keys with significant meaning are the only sensible option, but they are few and far between.
    Lol - missed that. The secret of all wise technical (or perhaps all) assertations - always include a qualification\ caveat.
    I guess it is like many things to do with relational databases. A good Logical model does not necessarily (notice how I did it too?) translate into a good physical model. I'm also a little sceptical as I've seen surrogate keys misused (e.g. surrogates used to a mechanism to prevent duplication rather than as an identifer of an already unique row - bad implimentation rather than a problem of surroagte keys per se but it put me off them in my early days).
    Testimonial:
    pootle flump
    ur codings are working excelent.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •