[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