MS Access Developers the Best Error Handler

I belong to a Skype group of 24 developers that specialize in MS Access, MS SQL, MySQL database, PHP development, and Dot Net development while using the “Code On Time” - (COT) commercial framework.

Most of us have at least 30 years of software development experience and are also database experts. A lot of the group actually works as a database administrator consultant.

My buddy Bill Walker started a great conversation about MS Access development error handler that impressed us all. I thought it would be a great idea to share the below info with everyone else.

Here are some of the discussions about software development and different opinions:

Bill:
I have been getting into VS and EF myself recently. I have had to stop temporarily to care for some legacy Access ERP systems.
I have about a dozen different Access apps all at one company. I'm putting the finishing touches on a central control application which allows us to manage all the apps and the users from one application.
From this app one can manage all users and permissions. View all open/closed apps. By who, what computer, OS, CPU, version etc. All errors generated on any app are centralized and can be viewed or reported from this app.

Call us for now and the first consultation is free at: 732-536-4765

John:
Bill it sounds like something a lot of companies could use to manage Access apps on their systems. That has always been a huge IT support problem.
It is part of the reason they hate Access

Bill:
The new global error handler also reports about 15 pieces of information about the computer plus error data such as procedure name and line number. We have also added a call stack trace which will show how the user got to this procedure.
It has been fun putting is all together.

Ted:
About 200 years ago, I put something together which allowed a support desk to analyze what was on a particular desktop. Windows based, it pulled up all the installed stuff, that was before total lock down came in, so fixes could be applied. Bill's job sounds much more fun.

Apropos Italy. I'm closest but not going. Too much on at the moment. To be honest, I'd rather like to stay with Dave in Florida fishing, racing cars, etc.
Like John and Alan, I keep in touch off the main group as necessary.
My latest challenge is joining a German web site selling rifle parts. Google Translate is good but keeps throwing me where I don't need to be.
Ho Hum!

Bill:
@Ted, I like that '200 years ago'. I think I will steal it from you.
Yes, it is possible to gather information on all applications installed on each computer that opens one of our apps. It's not instant but doable. I like gathering Installed Memory and available Memory. Both at startup and Available memory again when an error is generated.

Bob:
@Bill - interesting comment about your MS Access error tracking procedure. Care to tell more about the stack trace and ability to tell how the user got to the procedure they encountered the error?

I do a lot with Access and many of the errors I get are Access internal errors or are errors arising from some VBA code associated with a form. I don't really see how I could get any trace info to help debugging. Feel free to email me directly to My Email if you like as I am not sure others here are interested in Access.

Bill:
OK, here goes.

As you probably know Access has no mechanism to report the name of the procedure an error occurs in like other systems, so one must be made, or borrowed.
At the beginning of every procedure I write the name of the procedure to an Array, pushing it so to speak onto the array. At the exit of the procedure (means the procedure code completed w/o error) I pull the procedure name back off the array. This push and pull goes on and on building up the array and then pulling them back off.
I do the same for entering and leaving forms. This gives me a path from the form down through all the procedure private or public. The array builds up, then as goes back down unless an error occurs then I just read the elements of the array and there you have it. Simple as pie, a call stack trace.

Bob:
@Bill, so do you write each record out to a log file for your stack? Any concerns as to performance hit? I have one app that has 40 users per day and I would be concerned about the added OH. I already log before/after contents of key tables w/ who made the change and opening of key forms to see what is being used statistically.

Bill:
No Bob, No overhead to speak of it all takes place in memory, no writing to files or tables. You just have to be careful not to exit any procedure before you hit the pull from array code. I have noticed no performance hits do to this method.
The call stack trace only gets written out when an error occurs. Then I write the error out to a log file, a SQL table and finally send an email. Then I warn the user that the application is shutting down. Of course I don't shut down for recoverable or expected possible error conditions.

Bob:
@Bill - Thanks.

Custom Software Development and Remote DBA Services:

If you need any MS Access Developers or Dot Net development our team of highly experienced and professional developers can provide an efficient, cost-saving solution.

In addition, we provide remote DBA services for MS SQL or MySQL database. We can work on your data migration from old versions of MS SQL or MySQL to the latest and greatest database engine versions.

Check our database design and Reverse Database Engineering services as well. We have Microsoft MVP SQL experts with more than 30 years of experience.

For more information please contact us or give us a call at: 732-536-4765. The first consultation is free and we love to hear about how we can help.