Yes, the code is VBA, I'd adapt it to access vba to execute. My question, you are correct is how could I trigger it w/o access being open?
Altho, that makes the mind wonder, if I could adapt that to a vbscript. hmmmm...amazing what the mind can think of with just a few simple bits of assistance
You read my mind.
The first point I am trying to make is, while dbGuy is right of course, Ron's webpages (that one included) are targeted toward Excel, yet that code is almost 100% relevant to the Outlook object model, and can be ported to any Office program with extremely minimal adjustments, if any.
The next point I was going to make, which you have now stated, is.....it sounds like VBScript might be a solution for you. I have written many VBScripts which essentially execute against VBA object models, in cases where I don't want to cause an actual Office program to open in a typical, visible, user-interactive manner. If you are somewhat familiar with VBScript and are comfortable using its syntax along with late-binding the Office automation, that's probably your solution. Be aware that this will still mean the Office program you are referencing in your VBScript still needs to be installed on the host user's machine. But the advantage of the VBScript--which I assume is the advantage you are after--is the triggering aspect, you will gain the advantage that to trigger this code, Outlook does not need to be open and the script can be called from virtually any context you can think of, stealth mode, so to speak.
I'd probably just double check that the code you have contains no references to Excel (eliminate them if it does), and then go with VBScript & Outlook automation.