[AccessD] Yes. Another Silly Access Question.

Drew Wutka DWUTKA at marlow.com
Wed Oct 29 13:41:32 CST 2003


Works like a charm, don't you think?

Drew

-----Original Message-----
From: Charlotte Foust [mailto:cfoust at infostatsystems.com]
Sent: Wednesday, October 29, 2003 10:54 AM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] Yes. Another Silly Access Question.


That's the approach I use as well, Drew.  I give them the result they're
looking for and hide the details so they don't realize I did it right
instead of the way they wanted it done.

Charlotte Foust

-----Original Message-----
From: Drew Wutka [mailto:DWUTKA at marlow.com] 
Sent: Tuesday, October 28, 2003 9:54 AM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Yes. Another Silly Access Question.


I hear ya, on your situation.  I've been in the same boat many
times....fortunately, the people I work with don't have the first clue
of what I do/know, so I just do it my way anyways.  <evilgrin>

Drew

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


To quote my DI when I was in the military..."Mine is
not to question why.  Mine is but to do or die." 
heheheh

Sometimes, regardless of how much you try to talk
sense into people, they still wanna do what they wanna
do.  And Marketing wants to do what they want to do. 
Since their boss (The company Sr VP) is also my boss,
I lose....hehehe

--- Drew Wutka <DWUTKA at marlow.com> wrote:
> 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
> > > 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 
> _______________________________________________
> 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


More information about the AccessD mailing list