[AccessD] Yes. Another Silly Access Question.

Tried that.  Lost that battle.  Mainly because I shot
myself in the foot in two manners.

First, I designed an integrated Helpdesk/Asset
Management/Knowledge Base application from scratch
using MS Access.

Second, I designed and created a front-end for data
gathering for out telephone switching system, again
using MS Access.

So, now, because I created tools that are purpose
built to help me do my job, I am not the official
"Access Expert".  It sucks....hehehe

--- John Bartow <john at winhaven.net> wrote:
> Frank:
> I haven't got any programming advice for you but...
> 
> Since you are a Network Engineer maybe that gives
> you the opening to say "I
> don't know how to do that - maybe you should hire an
> outside consultant on
> this job".
> 
> I realize its a tough thing to say but it sounds
> like you're placing
> yourself in the future gun sights of the "big blame
> gun". It isn't your
> idea; it is bound to turn out badly in the future;
> but you're the one who
> "did" it, so its going to be your fault...
> 
> Maybe its not something you can do, but its worth
> considering.
> 
> JB
> 
> Learn from others mistakes: change "fool me once
> shame on you - fool me
> twice shame on me"
> into fool someone else once shame on you...
> 
> 
> > -----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 12:41 PM
> > To: Access Developers discussion and problem
> solving
> > Subject: Re: [AccessD] Yes. Another Silly Access
> Question.
> >
> >
> > That's because I *AM* a network engineer...hehehe 
> By
> > profession I tend to think modular....hehehe
> >
> > My boss wants a guarantee of no overlapping.  This
> is
> > the only way I can think of doing it without
> coding
> > mountains of logic into each form that I am
> creating.
> > The more logic I have to put in to account for
> every
> > possible contingency the larger the chance for
> errors
> > becomes.  Peeling off one record and storing it in
> a
> > temporary table will allow me to use the same
> logic
> > over and over again, plus guarantee that there
> will be
> > no overlaps.
> >
> > --- William Hindman <wdhindman at bellsouth.net>
> wrote:
> > > ...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
> 
=== message truncated ===