...I might be the wrong person to answer this first but I'm the <never ever use on error resume next> kind of person. If you don't have the time to write some proper error handling code at least make some error handling showing a msgbox (maybe just there has been an error contact blabla) and LEAVING THE SUB/FUNCTION IN A SAFE WAY. I've seen cases where a db frontend wasn't working properly for 5 years and noone found the error (or better noone knew what the error actually was) for that time. Date just seemed to get "corrupted". You won't be able to track bugs nor ensure if an error occours your data integrity is kept intact. Think of some giant transaction, one part fails 'cause of a typo in the sql. You won't notice anything till you see your data being wrong! It would only need a few lines of code for the error handling:
on error goto myerror:
some nice code
some nice garbage collection
msgbox err.description, vbcritical
Apel I understand you 100% and agree with you 99%. However, I am in a bit of a unique situation. I'm in the military and currently deployed to Saudi Arabia. I'm leaving here in about a month, and it is highly unlikely that there will ever be anyone back in my current job who knows anything about a database besides "click here to run" because I'm not going to be around to fix problems, and neither will anyone else, I wanted to prevent some sort of typo from causing an uninformed user to panic.