John Bartow
john at winhaven.net
Tue Oct 28 10:30:36 CST 2003
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 > > 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 > >