[AccessD] Strange Error 13 Type Mismatch error

Heenan, Lambert Lambert.Heenan at aig.com
Tue Oct 21 13:44:49 CDT 2014


One of the changes, in case you've not come across it yet, involves automating Outlook. (Though I think this might also have applied to Access 2007).

The long and the short of it is when you add a recipient to an Outlook.Recipient object, in previous versions of Access if Outlook was not running then Access would make it do so. Now you will get an error 287 "Application-defined or object-defined error". So you need to trap that error and fire up Outlook before resuming.  I handle it like this...

'----------------------------------------
    Select Case Err.Number
    Case 0 ' No Error
        DoEvents
    Case 287 ' Application-defined or object-defined error
    ' In Access 2007/2010 the call to .Recipients.Add generates this error if Outlook is not already running
    ' So here we will locate Outlook and then run it
    strOlPath = FindOutlook()
    If strOlPath > "" Then
        Shell strOlPath, vbMinimizedNoFocus
        Resume
    Else
        MsgBox "Error sending Email message. Please start Outlook then click the 'OK' button and we will try again.", vbOKOnly Or vbExclamation
        Resume
    End If

'----------------------------------------

And FindOutlook() looks like this...

'----------------------------------------
Function FindOutlook() As String
    Dim strOlPath As String
    Dim strFile As String
    Dim strTemp As String
    Dim n As Long
    ' try the folder that Access is installed in first
    FindOutlook = ""    ' default
    strOlPath = SysCmd(acSysCmdAccessDir)
    strFile = Dir(strOlPath & "Outlook.exe")
    If strFile & "" > "" Then
        FindOutlook = strOlPath & strFile
    Else
        ' not found. Search the Program Files folder
        strTemp = Split(strOlPath, "\")(0) & "\" & Split(strOlPath, "\")(1)
        With Application.FileSearch
            .LookIn = strTemp
            .SearchSubFolders = True
            .fileName = "Outlook.exe"
            .Execute
            If .FoundFiles.count > 0 Then
                For n = 1 To .FoundFiles.count
                    If GetFileName(.FoundFiles(n)) = "Outlook.Exe" Then
                        ' got it.
                        FindOutlook = .FoundFiles(n)
                        Exit For
                    End If
                Next n
            End If
        End With
    End If
End Function
'----------------------------------------
Lambert

-----Original Message-----
From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman
Sent: Tuesday, October 21, 2014 1:25 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Strange Error 13 Type Mismatch error


Internally it can hold a variant, so yes it can hold something other than a string.

How a control's value is structured internally I have no idea, but what's telling is your test: 

"When I put Me.IARed = "Red" in the immediate window I get the error. When I change the line to ' If CStr(Me.IARed) = "Red" Then' it works."

 That would indicate either:

1. What's in the control is not a string and the implied conversion does not work.

2. It's not going where you think it's going to get the value (.IARed points to something besides the control).

 For 2010, Microsoft messed around under the hood for the web stuff, but it was never really made clear what they messed with (and if anyone knows anything, that would be great<g>).  Just that many things that had worked in the past did no longer.  Their only real comment was "Syntax and type checking have been tightened and a lot of things allowed in the past are no longer."

  There's also the whole issue of ! (bang) vs . (dot) and the fudging that was done in forms to make the dot work for controls, which normally applies to properties and methods of a collection. I know in some instances a dot simply doesn't work when it should, so I've always stuck to the old bang syntax and never had a problem as a result.

  As far as the control names, reports have never seemed to be a problem, mostly I guess due to the fact that they are read only.  In reports, I leave everything with the same name as well and have never had a problem either.

  But in forms, early on I got caught a few times with controls and fields being the same name, so for a long time now, I always make sure their different.

Jim.



-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Doug Murphy
Sent: Tuesday, October 21, 2014 12:21 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Strange Error 13 Type Mismatch error

Hi Jim,

Can a text box hold anything but a string? I agree naming the control the same as the field is not the recommended way but when this report was created 15 or so years ago we just dragged the values onto the report. They are all hidden and just used for setting formats. By default Access will create controls this way and I have never seen this behavior before. The value put into the text box is a string. When testing the control in the Immediate window me.IARed returns the text value in the control. I am trying to understand the cause of the problem.

Doug

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman
Sent: Tuesday, October 21, 2014 9:03 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Strange Error 13 Type Mismatch error


 It's telling you it's not a string.

 2010 tightened down on a lot of things, like syntax and data typing, so some things you could get away with in the past, you can no longer.

 I'd start first by looking at how you place the value in the control.  Make it either a literal, or do the CSTR() on the way in.

 The other thing I'd do is rename the control.  Right now, it looks like the control and field have the same name.  That's never a good idea.

Jim.
 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Doug Murphy
Sent: Tuesday, October 21, 2014 11:51 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Strange Error 13 Type Mismatch error

Hi Gustav,

Yes, since this was originally created in Access 98 that was the way it originally was and other similar procedures in the routine still are. I just changed to period to see if that had any impact on the issue.  It didn't.
Both structures behave the same. 

IRed is the name of a text box that holds either "black" or "red". This controls the way a portion of the report displays. If I check the value of the text box in the Immediate  window it returns the correct value with no error. 

This report is for dog pedigrees and shows the dogs family tree back for 6 generations if the data is available.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock
Sent: Tuesday, October 21, 2014 1:04 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Strange Error 13 Type Mismatch error

Hi Doug

Have you tried using a bang: 

   Me!IARed

Or:

    If Me!IARed.Value = "Red"

What does

?  Me.IARed

return?

/gustav

-----Oprindelig meddelelse-----
Fra: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] På vegne af Doug Murphy
Sendt: 21. oktober 2014 02:07
Til: 'Access Developers discussion and problem solving'
Emne: [AccessD] Strange Error 13 Type Mismatch error

Folks,

Ran into an interesting issue in moving an application to Access 2010. The application that was originally developed in Access 98. Moved to Access 2003 and it ran fine. Moved to Access 2007 and it ran fine. In Access 2010, after fixing references etc, when we attempt to run a report that has some code behind that sets formatting we get the "Error 13, Type Mismatch" message.
The line that throws this error is ' If Me.IARed = "Red" Then' where IARed is a hidden text box holding a text value of red or black. When I put Me.IARed in the immediate window it returns the value in the text box. When I put Me.IARed = "Red" in the immediate window I get the error. When I change the line to ' If CStr(Me.IARed) = "Red" Then' it works.

Any idea what is happening here? As I said this worked well in previous versions and I do this all the time in other applications. I did decompile the application and compile, then compact several times. The application compiled with the original code, but would error when running.

Doug 

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



More information about the AccessD mailing list