Bill Benson
bensonforums at gmail.com
Tue Aug 19 21:02:36 CDT 2014
You hurt his feelings Mark, now he's gone and stepped down from the MSFT B.O.D. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark Simms Sent: Tuesday, August 19, 2014 9:07 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Most common problems/situations Having to build in user-level access/security. They could have easily built this into Access forms and reports. Instead, we have to code this in VBA classes. Let's send this to Steve, The multibillionaire Ballmer. "Thanks Steve for forgetting us....and here's hoping your investments work-out". > -----Original Message----- > From: accessd-bounces at databaseadvisors.com [mailto:accessd- > bounces at databaseadvisors.com] On Behalf Of Arthur Fuller > Sent: Tuesday, August 19, 2014 5:10 PM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Most common problems/situations > > Thanks so far for your input. > > You raise an interesting issue, Jack; actually, a large issue, but as > yet I'm not quite sure how to fit it into the topic that I'm currently > writing about. So let me sketch a scenario. > > I inherit an Access project containing lots of forms which in turn > contain a few combos and listboxes and perhaps even radio buttons. > Some, perhaps most of their data sources are SQL statements rather > than named queries; that's my first point of attack. > > The first point leads to the second, which I call Atomic v. Molecular > Queries. Use your chemistry experience to figure out what this means. > If > you can't get there, then this is what I mean: > > 1. Nothing should be table-driven; absolutely nothing. > 2. All combos/lists and by extension forms, should have data sources > not directly bound to tables, but rather named queries, which can be > reconsumed in many contexts throughout the given app. > 3. The reason for 2 is that the logic contained therein is portable to > any new back-end that might be required. (Maybe this doesn't affect > your particular situations and apps, but I have suffered this walk > through the park enough times to know that I ought to design for > change, and keep all options open -- and that extends beyond > db-implemenation, fe-implementation, and even Virgin 2.0. > 4. To sum up my design strategy, it consists of two parts: a) Design > for Success; and b) Design for Failure. What this translates into is > this: > Imagine that the app you deliver causes massive success for the > client; this will necessarily involve failures to design for scale > (they wanted it cheap and fast, and you delivered what they wanted, > but now the anticipated customer-base has grown from 1000 to 1000k and > that success has created significant new problems). > > My mantra is "Design for Success". (Else why hire me?) This translates > into anticipation of the hi,deous prospect that the client might be > right, and the business will succeed, in which ugly event, you might > have a contract extending for years, and thus be able to feed your > kids and pay your mortgage for years -- even though you thought > you'veten solved the basic problem, and thought yourself free to move > on. > > Bad news (or good, depending on your perspective). Let's call this > Fuller's Eighth Law: bad deliveries result in aborted projects; > successful deliveries result in Requests for Improvements, or to put > in crassly, future income for you. Fuller's Ninth Law: Quality Info > demands further Quality Info (this goes under several names, the most > current being Big Data, but the principle is the same: crunch and spin > -- at the end of the day, that's what it's all about). > > As for me, I design for success. I feel that if I cannot contribute to > massive success in the given client's adventure, then I have failed. > The > client's focus is on increased market-penetration and hence revenue, > and some percentage of the cake. > > I am no expert in any of these domains, but am acquainted in all of > them. I want to play in this arena. Ideally, I'd like to find somebody > who can appreciate what I can bring to the table. To put it another > way, Retirement is Boring. > > I'm working on an eBook now, and think I am going to be at least a > couple of weeks late, and maybe a month, but I want to get it right, > and if it takes an extra month, then so be it. It's all about the > reader, not the royalties. That's my mantra. > > The project has a specific goal, and is envisioned as the first of six > eBooks. That's why I am asking about the most common problems and > solutions that Access developers face. I think that I've covered my > personal list, but I need more -- I have worked in several small > niches, and you have worked in others. We share common problems, but > we have also delivered slightly odd variants of same, not to mention > unique solutions to bizarre problems. > > I'm interested in all of these. This is going toward an eBook, and if > anything you contribute ends up included in said work, you shall be > credited for your contributions. > > I don't think a lot of money will result from this task, but I think > that someone needs to do it, and have nominated myself as the > tasktician (I don[t think that's a word,but it's the best I could do > at the moment: > it > means that I shall vet the contributions, by fiat, and decide what is > worth inclusion. That might sound dictatorial, but hey, it's my > project, so I get the Veto; at the same time, any contributions you > submit shall, if used, be credited in the final output. (After all > these years on these various threads, I think you can trust me to > credit any contributors.) > > That said, I am most interested in your generalized descriptions of > common problems facing Access developers. I have listed those that > came to me while writing this email. I sincerely invite others, and if > necessary to illustrate the problem, a little descriptive info. > > Thanks in advance. I cannot promise that your contribution will be > used in the forthcoming eBook, but if it is, then I guarantee a > citation. > > > -- > 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