Module compiles, exicutes okay but can't create accde

[GraeagleBill]

I'm getting text messages this morning from whoever is experimenting with MedCheck. You're welcome to do that, but change the CONST strBillCell and strCarolCell to your own numbers so I don't get hammered with messages. Also, I'm paying for the Twilio texting service, so don't go overboard with the texting.

[Micron]

It's not me!

[isladogs]

Two messages were from me. I had a hunch about your function. I tried removing the dummy part so you just need to call MedCheck rather than MedCheck(0).
That worked but unfortunately it didn't help solve the issue with Autoexec.

Two more ideas you could try
1. Change your TestMedCheck to a function and run that from Autoexec instead
2. Scrap the Autoexec and run TestMedCheck from the load event of a startup form

I've removed the file now so any further messages won't be from me!
Suggest you ask the mods to remove the attachment so no one abuses your messaging service.

BTW What do you think of Twilio? I set this up about 4 years ago so schools could send multiple messages to parents using the same article as you.
I later extended it to voicemail and also to handle incoming voice and text messages.

[GraeagleBill]

When I first wrote the initialization code, AutoExec was simply RunCode MedCheck() and the function Public Function MedCheck(). I added all the Dummy stuff later in my attempts to solve the OP.

I didn't try your idea of making TestMedCheck a function.

While I could certainly scrap AutoExec and startup an invisible form, that tends to make for a disconcerting screen flash when the function runs. MedCheck fires at set times of the day via Windows Scheduled Task.

I have Twilio installed in three other apps and the users really like having that functionality. Those apps all have sizable user registries that include their phone numbers, both cell and landlines, plus their EMAs. As such, selected portions or the entire registries can receive text messages, voice messages or emails. While Twilio isn't the email client for emails, all the communication functions stem from a single form. One of the apps is a bit of a pain, as their ISP has limits on the number of EMAs with a single email. The apps settings includes a field wherein that limit can be specified and the app partitions the recipients accordingly. The user sees the partitioning and sends the email one partition at a time. Here's an example of what I mean:
as each partition is clicked the app places the formatted names and EMAs on the Windows Clipboard which is then pasted into a recipient pane of the email. It could have been made a bit simpler from within Access if ALL the users of the app used Outlook, but such is not the case. As it is, I don't have to be concerned with all the environments subject to change. I got a bit off track here of what you asked, but I tend to clump all these considerations together when the subject comes up.

[isladogs]

1. All applications that are designed to send bulk email will limit the number that can be sent at once. This is to prevent such emails be classified as spam and blocked by the provider.

2. You could use an alternative method of sending emails from Access - CDO. Using CDO means Outlook isn't involved at all.