Frank Tanner III
pctech at mybellybutton.com
Mon Oct 27 12:41:27 CST 2003
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