[AccessD] Yes. Another Silly Access Question.

Drew Wutka DWUTKA at marlow.com
Tue Oct 28 13:39:45 CST 2003


Make table off of a select Top 1 query, then delete it.  Again, this raises
the issue of 'simultaneous' users, which is why I recommended adding a
'toggle' field, to set that first, before doing anything else.

Drew

-----Original Message-----
From: Frank Tanner III [mailto:pctech at mybellybutton.com]
Sent: Tuesday, October 28, 2003 12:34 PM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] Yes. Another Silly Access Question.


I just want to be able to take record off of a
database.  Basically the first available one, no
specific criteria and plug it into a table" made via a
make table query.

The way I thought of doing it is pretty crappy.  I
thought about making a form (hidden) that uses that
database as it's bound property.  Then on form open
running a make table query to fill the "made" table
and then a delete query to selete the record, then the
invisible form shuts down.  But that's a pretty crappy
way of doing it.

--- Drew Wutka <DWUTKA at marlow.com> wrote:
> If you must you must.  What question do you have
> specifically about
> 'peeling' the record?
> 
> I would still put a flag in the main table, so that
> at the very start of the
> process, you set the flag, so the next instance of
> the process gets the next
> record.  Then I would copy the data to the local
> table, once copied, I would
> then simply delete the one on the server.
> 
> Is your question regarding code required to do it?
> 
> Drew
> 
> -----Original Message-----
> From: Frank Tanner III
> [mailto:pctech at mybellybutton.com]
> Sent: Monday, October 27, 2003 1:28 PM
> To: Access Developers discussion and problem solving
> Subject: RE: [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
> > > >
> 
=== message truncated ===

_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


More information about the AccessD mailing list