DoCmd.SendObject and CDO

  • Thread starter Thread starter Deleted Bruce 182381
  • Start date Start date
D

Deleted Bruce 182381

Guest
Do these methods for sending emails work in Access365? A friend told me MS Exchange stopped working with his Access/Outlook mail merge app.
 
It isn't Access 365 that is the problem - it is "New Outlook" that won't play the mail game by the old rules.

Regarding CDO: If you can get into VBA Window >> Tools >> References and check "Collaborative Data Objects" then you can send e-mails by defining the (.To, .CC, .BCC, .From, .Body) fields you want, similar to using VBA to open an Outlook mail object. You can find CDO online if you don't have it. With CDO, you can't manipulate received mail but you can create and send mail. CDO cannot use DoCmd.SendObject because it is a simple implementation of SMTP protocol, bypassing MS MAPI (Mail Application Program Interface). If you can create the mail object with CDO and can create a file to be attached to the mail object, you can send that kind of mail with CDO.

DoCmd.SendObject depends on a mail client that supports conformance to MAPI and Component Object Model automation, and New Outlook doesn't do that. There are other mail clients such as Thunderbird that work (so I've heard) but I have never dealt with them. From what I can determine, to use DoCmd.SendObject, you must obtain a mail client compliant with the MAPI methods.

Could be that you just download "Old Outlook" and install it, or you could have a 3rd-party app. You must install this client, whatever it is, and then open Settings >> Apps and find the "default apps" link to let you make the new mail client the system-wide default mail app. After that, you should be good. Except that I don't know that Office 365 would let you do that for Classic Outlook. I would have to defer to other forum members for that kind of info.
 
Do these methods for sending emails work in Access365? A friend told me MS Exchange stopped working with his Access/Outlook mail merge app.
You need to revert back to classic Outlook though. New Outlook won't work.
 
I blatantly refuse to use GraphAPI with new outlook.
At the moment it is the only solution for working with received emails if you don't have classic outlook. As a private individual there may be alternatives to new outlook which you can use, but many businesses are unlikely to move away from new outlook.

There have been a number of presentations over the last 12 months from various user groups and although I have not yet experimented myself, I get the impression that GraphAPI is a PITA to set up, but once done is fairly straightforward to use - although probably not as convenient as working with classic
 
I have used CDO to send email from Access for over 20 years.
It is easy to setup but only works for sending emails. Use late binding and no additional reference is needed.
I have an example app for testing email account settings with CDO

Agree that the Graph API is a complex alternative and whilst CDO remains available, I see no reason to change.
BTW You would use the Graph API with Access not with New Outlook
 
Very few apart from Graph API
I believe some people have used Thunderbird with Access but I've never tried
 
One thing I'm not clear about with classic outlook - support ceases in 2029. But does that mean classic outlook will stop working? Support for access 2010 ceased whatever time ago, but it still works, as do earlier versions of windows. The bigger risk to me, supporting a number of commercial clients, is that it wont be possible to install classic outlook when they buy new computers. So I need a viable solution - with the added complication that for a period of time, some users will have classic outlook and some new outlook.

It also seems that you cannot have classic and new installed side by side which makes testing difficult since GraphAPI requires new outlook style connection to the email server (unless I've got that wrong?)

I understand that you can manually drag and drop emails from new outlook to a folder or folders where it is saved as a msg file - same as classic. OK requires manual intervention to make that happen, but I'm just playing with the idea that if the relevant library files can be installed in the VBA, it will be possible to open the msg file to extract attachments etc.

The other way of looking at emails is sql - fine for reviewing the sender/header/message/etc, but not able to see attachments. However I somehow doubt that will work with new outlook
 
Perhaps these functions are useful for someone. I use them for saving and loading *.MSG Files. I don't remember where I found them:
Code:
'For Windows 2000 or later. Requires a reference to:
'   Microsoft CDO For Windows Library
'   Microsoft ActiveX Data Objects 2.5 Library
Function SaveMessageTofile(ByVal PathFile, ByRef Msg As CDO.Message) As Boolean
    ' https://www.vbforums.com/showthread.php?879991-RESOLVED-Save-Email-as-Draft-do-not-send
    On Error GoTo Err_SaveMessageTofile
 
    Dim IDataSource As CDO.IDataSource
    Dim Stream As ADODB.Stream
    SaveMessageTofile = False
    Set IDataSource = Msg
    Set Stream = New ADODB.Stream
    With Stream
        .Open
        .Type = adTypeText
        '.CharSet = "us-ascii"
        .CharSet = "utf-8"
        IDataSource.SaveToObject Stream, "_Stream"
        .SaveToFile PathFile, adSaveCreateOverWrite
        .Close
    End With

SaveMessageTofile = True
Exit_SaveMessageTofile:
Exit Function

Err_SaveMessageTofile:
    MsgBox Err.Description, vbOKOnly + vbExclamation, "Error"
    Resume Exit_SaveMessageTofile
End Function


'For Windows 2000 or later. Requires a reference to:
'   Microsoft CDO For Windows Library
'   Microsoft ActiveX Data Objects 2.5 Library
Function LoadMessageFromFile(ByVal Path, ByRef Msg As CDO.Message) As Boolean
On Error GoTo Err_LoadMessageFromFile
Dim Stream As ADODB.Stream, iMsg As CDO.Message, IDataSource As CDO.IDataSource
    
    LoadMessageFromFile = False
    Set Msg = Nothing
    Set Stream = CreateObject("ADODB.Stream")
    Stream.Open
    Call Stream.LoadFromFile(Path)
    Set iMsg = CreateObject("CDO.Message")
    Set IDataSource = iMsg.DataSource
    Call IDataSource.OpenObject(Stream, "_Stream")
    Set Msg = iMsg
 
LoadMessageFromFile = True
Exit_LoadMessageFromFile:
Exit Function

Err_LoadMessageFromFile:
    MsgBox Err.Description, vbOKOnly + vbExclamation, "Error"
    Resume Exit_LoadMessageFromFile
End Function
 
Last edited:
It also seems that you cannot have classic and new installed side by side which makes testing difficult since GraphAPI requires new outlook style connection to the email server (unless I've got that wrong?)

You can have both Classic & New Outlook. I have that in Windows 11 on 2 machines though only use Classic
 
Can you use Application.Object with Thunderbird client so Access can manipulate incoming/outgoing mail?

According to my research, no. You CAN deal with inbound mail but it doesn't use a single "container" object for all of its data. It is more of a multi-file scenario. It uses SMTP for outbound (like Outlook and CDO) and uses either IMAP or POP3 for inbound mail. Thunderbird is apparently based on a Firefox "core" for a lot of its code, so you know it will have web-like controls. I've never used it but when I was still working for the Navy, they allowed Thunderbird on the government computers. To do that, you know it had to pass muster through some really picky IT guys & gals.
 
I have seen some articles that suggest you can control Thunderbird from Access via SHELL commands. Otherwise, unfortunately, no direct control.
 
I wish MS would bring back the Access 2010 feature that sent emails to gather data entry and the email replies would automatically insert the data into tables. I used it a lot until MS deprecated it.

With M365 E3, I have opted to get the necessary end points using PowerAutomate, inserting the information into a List Table and then linking the List into Access.
 
Some say that MS Access is still in development & going strong - then I read articles like this & it is clear to me that the effectiveness of the application is being greatly diminished.
 
Some say that MS Access is still in development & going strong - then I read articles like this & it is clear to me that the effectiveness of the application is being greatly diminished.
Why do you attribute a change in Microsoft Outlook to Microsoft Access?
The absolute only built-in method in Access *potentially* affected by this change is DoCmd.SendObject. I say "potentially" because SendObject always required a (Simple)MAPI compatible email client. It always was the responsibility of the user to have such an application installed for SendObject to work. Also, Microsoft said (unfortunately, I don't have a reference) that they will add Simple MAPI support to New Outlook eventually.

Don't get me wrong. This change to Outlook is a slap to the face of all MsOffice developers and I'm as disappointed by it as everybody else here in the forum. However, it is not a change in Microsoft Access and you should not state that Access' effectiveness is diminished because the capabilities of an external application (Outlook) are diminished.
 

Users who are viewing this thread

Back
Top Bottom