[AccessD] Yes. Another Silly Access Question.

...I'm sorry Frank but this doesn't sound like much of a "reason" at all
...you're violating data normalization rules all over the place and creating
tables where a simple flag field and query would be much more apropos ...I
realize that you may not control things as much as you'd like but this
sounds like something a network engineer would build rather than a database
designer ...I thought Drew was on the mark before and even more so now :((((

William Hindman
<http://www.freestateproject.org> - Do you want liberty in your lifetime?


----- Original Message ----- 
From: "Frank Tanner III" <pctech at mybellybutton.com>
To: "Access Developers discussion and problem solving"
<accessd at databaseadvisors.com>
Sent: Monday, October 27, 2003 12:55 PM
Subject: RE: [AccessD] Yes. Another Silly Access Question.


> 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.
>
> --- Drew Wutka <DWUTKA at marlow.com> wrote:
> > Just curious why you would want to physically 'move'
> > the data, instead of
> > just adding a field to track the 'status' of it.
> > You could have a byte
> > field where 0 is 'new', 1 is 'in use' and other
> > numbers could represent
> > where the data 'ends up' as you put it.
> >
> > Drew
> >
> > -----Original Message-----
> > From: Frank Tanner III
> > [mailto:pctech at mybellybutton.com]
> > Sent: Monday, October 27, 2003 10:41 AM
> > To: Database Advisors
> > Subject: [AccessD] Yes. Another Silly Access
> > Question.
> >
> >
> > Ok....Here we go.  Hang on to your
> > bloomers....hehehe
> >
> > I am using a sort of "check out" system in order to
> > ensure that duplicates are not contacted.  It works
> > like this...
> >
> > I have a back-end database table that is my master
> > table of records.  I want my people to click a
> > button
> > called "Get Information" that will read the first
> > available record into a "make table query" to create
> > a
> > temporary local front-end table and delete it from
> > the
> > master table in the back-end.  Sort of like checking
> > out a book from the library.  Once this record is
> > pulled from the master table in the back-end, it
> > will
> > never go back into that back-end table.  it will go
> > into other back-end tables, depending on the
> > disposition of the information.  Sorta like this...
> >
> > Get Information pulls "next available record" from
> > tbl_customer_info.  Preferrably via a make table
> > query, and stuffs it into a front-end table called
> > tmp_customer_info and completely removes said record
> > from the back-end tbl_customer_info table.
> >
> > Once the local work has been done it will be "saved"
> > to a different back-end table and the local table,
> > tmp_customer_information, will be cleared/deleted.
> > Thus the need for some sort of make table type of
> > query.  Then the next time that a user clicks the
> > Get
> > Information, this process starts all over again.
> >
> > I'm kind of at a loss as to how to do this.  Any
> > ideas?  Thank you.
> > _______________________________________________
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> > _______________________________________________
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
>
> _______________________________________________
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>