Ken Ismert
KIsmert at TexasSystems.com
Wed Oct 29 18:09:44 CST 2003
Frank, A reasonable compromise: * Do your interface based on the sensible, normalized single table approach. This is your source data. * Maintain 3 separate summary tables to satisfy the marketing idiots. You could either update them each night in bulk, or update them record by record throughout the day, depending on their needs. This way, they have their data the way they like. You don't care if they trash it, because you can always rebuild it. Your development time would be about the same, because the time saved implementing the interface the correct way will be offset somewhat by the burden of maintaining the extra tables. This will still be easier and more reliable than their bone-headed approach. As long as their summary data is read-only, this should work. Since a typical database has lots of lookup and other ancillary tables, you can easily hide the 'real' data table in plain sight. Even if the VP did by chance pick that table out, you could say it was a 'work' or 'staging' table, or some such rot. Even if they do a code review, it is still a defensible strategy: it saved development time, maintains a backup, etc... Of course, my evil side would suggest: Maintain three QUERIES off of the single table, but name them: TABLEQuestionsFilledOut TABLEQuestionsDeclined TABLEQuestionsAskLater When they don't see them in the Tables tab, simply say you moved them. They'll likely swallow it; after all, their names do start with "TABLE" <evil laugh> -Ken -----Original Message----- From: Drew Wutka [mailto:DWUTKA at marlow.com] Sent: Wednesday, October 29, 2003 2:15 PM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] Yes. Another Silly Access Question. You don't have real novices then...grin. The people I work with/for aren't intelligent enough to even figure out they need to click the 'Tables' tab to see the tables.....well, my co-worker is, but he and I work together, not against each other. Drew -----Original Message----- From: Frank Tanner III [mailto:pctech at mybellybutton.com] Sent: Wednesday, October 29, 2003 1:47 PM To: Access Developers discussion and problem solving Subject: RE: [AccessD] Yes. Another Silly Access Question. It works like a charm...... Presupposing they don't do some sort of code review. Even a novice can say, "Hey! We told you to make three tables. There's only one here." --- Drew Wutka <DWUTKA at marlow.com> wrote: > Works like a charm, don't you think? > > Drew > > -----Original Message----- > From: Charlotte Foust > [mailto:cfoust at infostatsystems.com] > Sent: Wednesday, October 29, 2003 10:54 AM > To: Access Developers discussion and problem solving > Subject: RE: [AccessD] Yes. Another Silly Access > Question. > > > That's the approach I use as well, Drew. I give > them the result they're > looking for and hide the details so they don't > realize I did it right > instead of the way they wanted it done. > > Charlotte Foust > > -----Original Message----- > From: Drew Wutka [mailto:DWUTKA at marlow.com] > Sent: Tuesday, October 28, 2003 9:54 AM > To: 'Access Developers discussion and problem > solving' > Subject: RE: [AccessD] Yes. Another Silly Access > Question. > > > I hear ya, on your situation. I've been in the same > boat many > times....fortunately, the people I work with don't > have the first clue > of what I do/know, so I just do it my way anyways. > <evilgrin> > > Drew > > -----Original Message----- > From: Frank Tanner III > [mailto:pctech at mybellybutton.com] > Sent: Monday, October 27, 2003 1:27 PM > To: Access Developers discussion and problem solving > Subject: RE: [AccessD] Yes. Another Silly Access > Question. > > > To quote my DI when I was in the military..."Mine is > not to question why. Mine is but to do or die." > heheheh > > Sometimes, regardless of how much you try to talk > sense into people, they still wanna do what they > wanna > do. And Marketing wants to do what they want to do. > > Since their boss (The company Sr VP) is also my > boss, > I lose....hehehe > > --- Drew Wutka <DWUTKA at marlow.com> wrote: > > 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 > === message truncated === _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com