I guess I've just never actually seen a good Access based application. *Shrug*
-Stoic Joker
I've seen a couple of good ones. The problem is, with any enterprise, once something is *good* they want *better*. Which in most cases means *bigger*. The road to hell, and all that...-wraith808
Agreed, it usually goes something like this:
Brass: This thing is great, but can we...
IT: oh shit.
...Been there. :)
-Stoic Joker
Unless told, a user would have a hard time detecting that any of my applications were written in Access... certain characteristics of how graphic controls are rendered and the occasional scrollbar appearance might tip off an expert, but mine run resolution-independently in full screen and look exactly like tools focused on specific tasks, not "databases".
And my answer to management requests such as described above was typically either, "it already does that, let me show you" or "is a week quick enough for you"? To the same questions, DP usually responded with "can't do that, not possible" or "how about next year?" and "we'll have to add staff so your cost center better budget for it". Those responses made my living, thank you very much.
However, the comments about database scaling are right on. Many years ago I wrote/sold a telemarketing app in Access that pushed almost 2 million records per table but behaved quite properly, and that was in the days of 486s and 1Mb of RAM. But even with today's incredible (from an old coot's perspective) PC hardware, beyond that scale, or for a distributed environment with hundreds of data entry clerks not geographically local to each other all sharing the same data, or for any real-time environment scaling larger than a small group, a server-based approach is the only responsible thing a consultant should recommend, not Access.
But there is (or used to be, at least) a middle (and lower) ground, especially for individual efforts, for small businesses, or for entrepreneurial groups within larger organizations, where the long term management of the data and processes is less important than an accurate, quick solution to an immediate need, one that requires no maintenance whatsoever and just "works".
My point is: don't blame Access the tool, but rather the person who uses it inappropriately (aka the non-professional tyro) or the inappropriate contexts it sometimes is offered for (bad consultant).
I might also add that anticipating the user's true needs (the ones he hasn't or can't express or, frequently, doesn't even understand yet) and addressing them "gratis" at the core of the app
from the beginning saves much headache later. This requires an understanding of systems in general, not just programming and data structures.
Always deliver an 11/10ths product, tolerate no less of yourself.
That's it from me. Apologies again for being so long-winded.
Cheers, everyone. :)