Microsoft Access - Has anyone used "Access Documentiation and Analysis Program Add-In"?

Asked By chaz d'chaz on 16-Oct-14 03:25 PM
The bosses are thinking of getting this:

https://www.fmsinc.com/MicrosoftAccess/documentation/index.html

to assist in managing a bunch of access dbs here.

Can anyone offer an opinion of its value?

thx
Robbe Morris replied to chaz d'chaz on 16-Oct-14 04:37 PM
I did a review on one of their products a long time ago.

http://www.nullskull.com/articles/20020505b.asp

As for this particular product, I don't think you'll find much that offers more than this.  Managing large groups of Access databases is something that most IT groups desperately try to avoid.
chaz d'chaz replied to Robbe Morris on 16-Oct-14 05:04 PM
 Managing large groups of Access databases is something that most IT groups desperately try to avoid.

...And yet...
Pat Hartman replied to chaz d'chaz on 30-Oct-14 11:22 AM

I hate to disagree with Robbe but I don't believe "Access" databases are to be avoided at all costs.  Perhaps, your applications might be better with SQL server back ends rather than Jet or ACE but Access itself is a fine development tool and without it many small companies would have no ability to create custom software.  Even business units of large companies rely on Access to develop custom applications that the main IT department doesn't believe are "important" enough or have the time or resources to develop.  Access is frequently confused with its closely associated database engines Jet and ACE but Access can use any data source that provides an ODBC interface and Jet and ACE are completely separate from Access and are used by many other application development tools if they need to keep data locally so it is really not fair to blame "Access" for the perceived weakness of Jet.  As an example, the business tax software I buy every year uses Jet as its data store.  I don't know what the app is written in but it isn't "Access".


I own several FMS tools and find them invaluable when adopting applications built by other people.

chaz d'chaz replied to Pat Hartman on 30-Oct-14 01:30 PM
Disclaimer: Pat and Robbe on the same thread: I am not worthy.

Pat, unless I misunderstood, you're helping Robbe make his point, which is that many IT dept's don't want to deal with Access.  That doesn't mean they don't use it, which supports your point about its uselfulness.  It's revolutionary in that way...and that's what can create a problem on an enterprise scale and...we've just come full circle...

This one here has no choice.  Users who (should but) don't know better muck things up. Developers create a patchwork of methods when standardization is optimal.  Managing a couple of these could be seen as an adventure, but managing dozens or hundreds of them in this environment isn't merely annoying, it's a black hole of time.

...And yet...
chaz d'chaz replied to Pat Hartman on 30-Oct-14 01:32 PM
"I own several FMS tools and find them invaluable when adopting applications built by other people."

Do you own the tool in question? Could you expand on this?
Pat Hartman replied to chaz d'chaz on 30-Oct-14 02:07 PM

Since you've found the FMS site, take a look through the articles.  I don't have a link handy but Luke Chung wrote an excellent article a few years ago regarding the place of Access in the universe.  He makes some excellent points about all the databases that are created and discarded either because they served their purpose or didn't do what was needed.  Only a few ever actually make it to the attention of the all powerful IT department.  Sadly IT looks at something useful created by a non-technical user and deems the product (Access) to be flawed and at fault because the techniques employed were technically unsound.  They never understand that to get to this point in the life-cycle, this application has gotten very important to its owner and has risen up the ranks to being necessary to the corporation.  When the department developed the app themselves, it was because the project was deemed unimportant and they couldn't get the necessary IT resources so they took matters into their own hands.  IT should be looking at the app as a working prototype and thanking the developer for the requirements gathering effort.  It is not productive for companies to forbid the use of Access.  Doing that simply forces people into Excel which is an even worse tool for "database" development and shows a complete lack of understanding of how businesses evolve.


I have a very long professional IT background but I left corporate IT in the 90's because the inmates were running the asylum.  I much prefer developing custom Access applications where I can actually produce meaningful products in a short time frame with a reasonable budget.  I don't think I ever worked on a mainframe project that included fewer than 5 people and was scheduled for less than a year (I only did new development projects) and many of them could be recreated by a single Access developer in a couple of months.  Once I discovered that Access could link to DB2 tables on our IBM mainframe and UPDATE them, I jumped ship at the earliest opportunity.  Of course, most of my early clients didn't have multi-million dollar IBM mainframes so my early databases relied on Jet but nowadays, everyone supports at least SQL Server so I rarely use Jet and ACE any more except maybe as a jumping off point.


Regarding Total Access Analyzer - I use it on every new application I take over and periodically on my own during development but always at the end to create some documentation.  This is not a tool you will use on a daily basis but it is invaluable in understanding an application created by a different developer.  I find the cross reference reports especially useful.

chaz d'chaz replied to Pat Hartman on 30-Oct-14 04:21 PM
If Access is going to be used as protyping for IT, it needs to be done according to a protocol specified by IT, or else it can easily be a waste of time.
chaz d'chaz replied to Pat Hartman on 17-Nov-14 03:37 PM
Pat, I need to amend my last post because I reread yours and I see that you were saying IT should thank the Access developer for the effort in requirements-gathering -- somehow I missed that and assumed you mean that IT should thank the Access developer for prototyping, not exactly the same thing.

Separately, have you heard of vbWatchdog for error logging?  Looks comprehensive, but I'm not sure if it renders home-grown error logging completely obsolete.  Interested in your opinion, if any.

http://www.everythingaccess.com/vbwatchdog.asp