Run-time error ' 2147417851 (80010105) Method'To' of object'_MailItem'failed

[Carsten Petersen]

Hello Forum!



When I am running this code on a Windows XP platform whit Outlook2010 and Access2010 the code are working,
when I am running the same code on a Windows10 platform with Outlook2010 and Access2010 the code are NOT working, it stops at
.To = Me.Emailkontaktperson

and gives this message " Run-time error ' 2147417851 (80010105) Method'To' of object'_MailItem'failed "

Do Forum have any suggestion to what are causing this???

Private Sub Kommandoknap35_Click()
Dim DocName As String
Dim objOutlook As Object
Dim objOutLookMsg As Object
Dim strBody As String
Dim DocPath As String
Dim rst As DAO.Recordset

'Me.txtBillingEmail is a text field on the invoice form that has the billing email
'On Error GoTo Kommandoknap35_Click_Error


If Me.Emailkontaktperson = "No billing email on file." Then
'When a customer has no email the system inserts the text
'"No billing email on file."
MsgBox "No billing email on file.", vbInformation, "Can't Email"
Exit Sub
End If


'The DocName is the name of the invoice report
DocName = "RapTilbud"
'First, we open the report to the screen using the invoice #
DoCmd.OpenReport "RapTilbud", acViewPreview, , "[Ordrenr]=" & Me.Ordrenr


'DocPath stores the complete path of the PDF
'DocPath = CurrentProject.path & "\Fakturanr" & " " & Me.Ordrenr & " " & Me.Kundenavn & " .pdf"
DocPath = "C:\Users\Carsten\Desktop\Tilbud2doo" & "\Tilbud nr" & " " & Me.Ordrenr & " " & Me.Kundenavn & ".pdf"


'Delete pdf if it exists
If Dir(DocPath) <> "" Then
Kill DocPath
End If

'Second, we save the invoice to the directory where the program is launched from
'we use the invoice number in the name of the file
'DoCmd.OutputTo acOutputReport, DocName, acFormatPDF, CurrentProject.path & "\Fakturanr" & " " & Me.Ordrenr & " " & Me.Kundenavn & " .pdf", False
DoCmd.OutputTo acOutputReport, DocName, acFormatPDF, "C:\Users\Carsten\Desktop\Tilbud2doo" & "\Tilbud nr" & " " & Me.Ordrenr & " " & Me.Kundenavn & ".pdf", False
'Close the report since it's no longer needed
DoCmd.Close acReport, DocName

'rst is opened to the options table that holds the subject and body templates
Set rst = CurrentDb.OpenRecordset("Select * from Masterdata")
'objOutlook will be used to refence Outlook in the program
'I recommend Outlook is open while the code is executing
Set objOutlook = CreateObject("Outlook.Application")
'Create a new message:
Set objOutLookMsg = objOutlook.CreateItem(0)
With objOutLookMsg
'Use the email field on the invoice for the To field
.To = Me.Emailkontaktperson
'Optional: copy another email address that will receive a copy of the pdf
'.CC = "any@what_ever.com”"

[pbaldy]

I had a similar problem, and it bugged the heck out of me. My eventual fix (workaround) was using a variable, which you wouldn't think would matter. Declare a string variable and then populate and use it.

Dim strEmail As String
...
strEmail = Me.Emailkontaktperson
.To = strEmail

[Carsten Petersen]

I had a similar problem, and it bugged the heck out of me. My eventual fix (workaround) was using a variable, which you wouldn't think would matter. Declare a string variable and then populate and use it.

Dim strEmail As String
...
strEmail = Me.Emailkontaktperson
.To = strEmail

Resolved thank you very much!!!

[pbaldy]

Happy to help and welcome to the site by the way! I stumped some great minds with that before stumbling on the answer while experimenting.

[ramirezx@ddmfg.com]

I had a similar problem, and it bugged the heck out of me. My eventual fix (workaround) was using a variable, which you wouldn't think would matter. Declare a string variable and then populate and use it.

Dim strEmail As String
...
strEmail = Me.Emailkontaktperson
.To = strEmail

-----------------------

I was having the same problem, your example work great for me, Thanks!

[pbaldy]

Glad it helped you!

[MiNiX]

I had a similar problem, and it bugged the heck out of me. My eventual fix (workaround) was using a variable, which you wouldn't think would matter. Declare a string variable and then populate and use it.

Dim strEmail As String
...
strEmail = Me.Emailkontaktperson
.To = strEmail

Dear pbaldy,
I had a similar problem after the creation of a new laptop with 64 bit Office. My previous one had 32 bit version installed and the VBA script worked.
I fixed the code by using a temporary variable and not directly from Cell(x, y) attribute as you suggested and it worked!!
I thank you very much for the hint. Can you explain me the technical reason for this solution?
Best regards.

[pbaldy]

I'm glad it helped you! I never got a definitive answer. It was speculated that the newer OS versions were trying to pass the object itself rather than the value within the object, and declaring a variable forced the result to be the desired string. Once I got it solved (or more accurately worked around) I stopped researching.

[MiNiX]

I'm glad it helped you! I never got a definitive answer. It was speculated that the newer OS versions were trying to pass the object itself rather than the value within the object, and declaring a variable forced the result to be the desired string. Once I got it solved (or more accurately worked around) I stopped researching.

Hi pbaldy,
Web is full of wrong and invasive solutions for this problem (they usually ask to reinstall Office or to drop some Windows registry key).
The only correct and easiest way to do is hidden inside this forum and I couldn't believe to find it after 2 days of useless searches!
Do you really think that the problem is the OS version or a particular patch? I have the same OS version (Windows 10) of my customer (who had the problem) but in my laptop the VBA code works.
The only differences are:
1) my customer laptop is new and installed from scratch
2) the version of Office 2016 (my customer had a 64 bit, while mine is 32 bit), but also after "downgrading" it to 32 bit, the code had the same error.

[pbaldy]

OS was my speculation because the only users I had that experienced the problem were those that had been upgraded. I had a client that had the same issue: code that had been working fine suddenly having this error when users were upgraded to Win 10. It could certainly have been something else. In my case, once I sorted it out it was on to the next crisis, so I didn't go back and try to isolate the culprit.