[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