[AccessD] Yes. Another Silly Access Question.

In this case, I'm not the inflexible one.  The
Marketing department is.

And since their boss is my boss, I lose....hehe

Not all of us network engineers are inflexible.  I am
a firm believer in there being more than one way to
skin a cat.

--- William Hindman <wdhindman at bellsouth.net> wrote:
> ...nah ...I was frowning at what I kindly refer to
> as a "notwork" type
> design! ...sorry Frank but I go round and round with
> network engineers all
> too frequently ...I'd rather take on reworking a
> design by a newbie than one
> done by a network type ...most newbies can be
> reasoned with! :)))))))))
> 
> William Hindman
> <http://www.freestateproject.org> - Do you want
> liberty in your lifetime?
> 
> 
> ----- Original Message ----- 
> From: "Drew Wutka" <DWUTKA at marlow.com>
> To: "'Access Developers discussion and problem
> solving'"
> <accessd at databaseadvisors.com>
> Sent: Monday, October 27, 2003 1:53 PM
> Subject: RE: [AccessD] Yes. Another Silly Access
> Question.
> 
> 
> > Is there a reason you have a big frown after
> thinking I was on the Mark!
> > <evilgrin>
> >
> > Again I concur.  The only reason I can think of,
> off of the top of my
> head,
> > for 'moving' records around, is if you actually
> have mobile databases.
> Even
> > then, you would still want a 'master copy' sitting
> there, in case one of
> the
> > mobile ones crashed.  I guess that's half
> replication! <grin>
> >
> > Drew
> >
> > -----Original Message-----
> > From: William Hindman
> [mailto:wdhindman at bellsouth.net]
> > Sent: Monday, October 27, 2003 12:07 PM
> > To: Access Developers discussion and problem
> solving
> > Subject: Re: [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
> 
=== message truncated ===