Messages - JohnFredC [ switch to compact view ]

Pages: [1] 2 3 4 5 6 ... 14next
Put it right up there with such classics as Stand on Zanzibar

Wow, a reference to Stand on Zanzibar!  That's by John Brunner.  What a book.. had a big impact on me.  Prescient.  Highly recommended.

General Software Discussion / Re: Fold
« on: June 14, 2011, 06:02 AM »
Enabling "display full path in title bar" did tile the first Explorer, but not the second.

Disabling taskbar autohide tiled the second Explorer (of my pair) so now it works!


I guess I've just never actually seen a good Access based application. *Shrug*

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

Agreed, it usually goes something like this:
Brass: This thing is great, but can we...
IT: oh shit.

...Been there. :)

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.  :)

Access with an Access backend (mdb) is wonderful for single person apps and good for small workgroups with a handful (say, less than 20) of simultaneous users.  Access as a front-end to SQL server or Oracle is a wonderful tool, plain and simple.

Some more "pithy" remarks:  8)

Friendly, powerful development tools and data do not an application make.  Good software is more about the UI metaphor, efficient data structure designs, data integrity, etc, etc. 

Access's brilliance is that it leverages any moderately intelligent person into data-driven application development. 

Access's downfall is that it leverages any moderately intelligent person into data-driven application development, even those who know nothing about application development.

DP departments most particularly hate it, because end-users tend not to be app-development savvy.  Give them Access, though, and they can make something that is functional for their department very quickly.  Then management wants DP to take over maintenance, extend the functionality, convert the app to a robust client/server environment.  Typically the original developer didn't know about relational forms, data integrity concepts, or efficient query structures, many-to-many tables, inside vs. outside joins, or what have you:  DP inevitably finds errors in implementation of major proportions.  Further, the kinds of functionality that Access enables with such ease (self-modifying reports, for instance, see my post above, or real-time self-populating pick-lists) are much more involved to create in the kinds of tools that DP uses and with the kinds of expertise that DP hires, adding to the budget needed to replicate the end-user designed functionality. 

So DP lobbies against end-user ownership of the data (and, by association, application development) via various (sometimes draconian) policies that restrict the use of end-user tools such as Access.  App development professionals who are qualified in other, DP-sanctioned tools are hired by DP, absorb the "bad" press, and repeat it without a second thought.  The result is that the line-of-business is stuck without the (sometime extremely simple) tools it desperately needs and in the fast-paced modern world, opportunities to enhance shareholder equity pass by.

Fortunately for developers like me, the more astute line-of-business management can see through the DP posturing toward the benefit of hiring a professional who can produce badly needed robust solutions very quickly (of course having DP miss its own deadlines over and over again doesn't hurt).

I've been in the business for 30 years on both sides of the fence: in-house corporate database development and delivery (very large unnamed bank) and subsequently as an outside (and successful) purveyor of those very apps built in Access.  We could debate the politics and best practices issues in another thread, but...

For the sorts of things that superboyac is inquiring about, Access is like a dream come true.

Whew, sorry for such lengthy opinionating!  :-\

General Software Discussion / Re: Fold
« on: June 13, 2011, 03:41 PM »
It's noted in the Readme that AutoHide has to be disabled for the utility to operate.
:-[ Sorry, I tend not to read readmes very closely.
edit: I'm curious. How many folders are you trying to open?
Just two.

Pages: [1] 2 3 4 5 6 ... 14next
Go to full version