William Hindman
wdhindman at bellsouth.net
Mon Oct 27 13:10:56 CST 2003
...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 > > > 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 >