[AccessD] Re: Yes. Another Silly Access Question

Frank,

This is still just a status.  But, it seems that
no one is going to convince you to design it the
correct way.  The correct way to avoid any possible
duplication is to have them in the same table.
A bad design is a bad design.  No amount of logic
you try to apply to it is going to change that.

With your design, you are going to have to synchronize
the future questionnaire people with the completed
and declined when they either complete it or decline
to complete it.  Where with a correct design, it is
a simple status change.

Good luck.

Robert

At 12:00 PM 10/27/2003 -0600, you wrote:
>Date: Mon, 27 Oct 2003 09:55:53 -0800 (PST)
>From: Frank Tanner III <pctech at mybellybutton.com>
>Subject: RE: [AccessD] Yes.  Another Silly Access Question.
>To: Access Developers discussion and problem solving
>         <accessd at databaseadvisors.com>
>Message-ID: <20031027175553.64430.qmail at web13408.mail.yahoo.com>
>Content-Type: text/plain; charset=us-ascii
>
>Because the back-end tables are going to be accessed
>by several people at once and we want to avoid ANY
>possibility of duplication.
>
>The reason why we're moving them to different tables
>after processing is for marketing to keep track of
>different functions based upon the data in tables
>specific to certain criteria.  IE.  Customers that
>fill out a questionnaire go into one table, customers
>that decline to go into another table, and customers
>that would like to answer the questionnaire later go
>into yet another table.
>
>The front-end itself has to be as generic as possible
>yet cover all contingencies based upon what someone is
>doing at a particular given point in time.