[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.

​