[AccessD] Yes. Another Silly Access Question.

That would be acceptable to me, whether or not it is
acceptable to them.  HOWEVER, it still doesn't answer
my original question.

Which was how to peel the record in the first place.

Then, regardless of how the END result is, my original
question would still remain the same.

--- Nancy Lytle <nancy.lytle at auatac.com> wrote:
> Why not a compromise?  Take the record from the
> Master Table, put it into
> temp and then put it into a new Table called
> Processed with a category
> column for completed, not interested and to be
> contacted later.  Then create
> three queries with each one giving you the full set
> of data for each
> category.  The problem is that once you separate the
> data, it is hard to put
> it back together again, kind of like Humpty-Dumpty,
> and you never know what
> future requirements there may be, been there, done
> that, don't ever want to
> do it again:(
> 
> Nancy Lytle
> EIS
> nancy.lytle at auatac.com
> 
> 
> 
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On
> Behalf Of Frank Tanner III
> Sent: Monday, October 27, 2003 1:46 PM
> To: Access Developers discussion and problem solving
> Subject: RE: [AccessD] Yes. Another Silly Access
> Question.
> 
> 
> As I see it the worst possible case scenario is that
> one record could become corrupt if the front-end
> gets
> whacked.  Because the front-end would only be,
> temporarily I might add, storing one record.  Ever.
> 
> Unfortunately, I was given a specific set of
> criteria
> as to how they wanted the back-end to be handled,
> and
> I cannot deviate from that.  So, given that I am
> trying to come up with the easiest, and most modular
> way of handling it.
> 
> They are adamant about having one back-end table
> that
> contains all of the records to be pulled from, one
> table that contains the records that have been
> contacted and have answered the questions, one table
> that contains the "not-interested" responses, and
> one
> table that contains the "call me back later"
> responses.  I am not privvy to why they want it that
> way, nor what they are going to do with it once it
> is
> complete.
> 
> --- "Heenan, Lambert" <Lambert.Heenan at AIG.com>
> wrote:
> > I'd suggest you look at adding a "CheckedOut
> Status"
> > field to the original
> > back-end table, and also a "Who checked it out"
> > field. Doing it this way
> > means you never need to move the data from table
> to
> > table, instead just
> > change the values in those two fields. In
> addition,
> > there's no danger of
> > data getting lost when and if the user's front end
> > copy gets trashed /
> > corrupted.
> > 
> > Lambert
> > 
> > > -----Original Message-----
> > > From:	Frank Tanner III
> > [SMTP:pctech at mybellybutton.com]
> > > Sent:	Monday, October 27, 2003 11: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
> 
> _______________________________________________
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com