William Hindman
wdhindman at bellsouth.net
Mon Oct 27 13:40:02 CST 2003
...and if you went to your boss and told him that the proposed design would almost certainly result in more problems, not less? ...but that there is a much simpler way to do it that won't ...most Sr VPs don't get there by failing idiot detection tests :) 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 2:30 PM Subject: Re: [AccessD] Yes. Another Silly Access Question. > In this case, I'm not the inflexible one. The > Marketing department is. > > And since their boss is my boss, I lose....hehe > > Not all of us network engineers are inflexible. I am > a firm believer in there being more than one way to > skin a cat. > > --- William Hindman <wdhindman at bellsouth.net> wrote: > > ...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 > > > === message truncated === > > _______________________________________________ > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com >