Results 1 to 5 of 5
  1. #1
    Lounger
    Join Date
    Apr 2002
    Posts
    38
    Thanks
    0
    Thanked 0 Times in 0 Posts
    G'Day,
    This is a really frustrating error. For months now, we have had a line of code that has worked wonders with no issues. Yesterday, this line suddenly started throwing Error 13: Data type mismatch. The line of code is as follows:
    Code:
    Set rsServices = dbServices.OpenRecordset("SELECT [ID] FROM tblTMPVoucherService WHERE [VoucherID] = '" & strVoucherID & "'", dbOpenSnapshot)
    The definition for these objects are as follows:

    Code:
    Dim rsServices As Recordset
    Dim dbServices As Database
        
    Set dbServices = CurrentDb
    I have checked the variable being passed (which is defined in the table as a string, hence the quotations) and it is looking good. Nothing has changed in the source tables or VBA since this was written and it has been working fine for months.

    This isn't the first time we have had Access do this to us. Normally, it's a query that stops recognising 'Max', so we change it to 'Last' (technically different, but works for us). Then, a couple of months down the track, you have to change it back. For no reason - that is annoying. This is in another league as I can't figure another way to get around this (nor should we have to - pity MS don't read this).


    Any suggestions?

    Cheers
    toncc

  2. #2
    Lounger
    Join Date
    Apr 2002
    Posts
    38
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Just carried out some testing, eliminating the' WHERE' clause has no effect, using 'SELECT *' has no effect and removing the SQL entirley and just passing the name of the table also has no effect. So I think I'm safe in assuming it is not anything to do with the SQL statement. Which makes me wonder just what it is.

    Cheers
    toncc

  3. #3
    Lounger
    Join Date
    Apr 2002
    Posts
    38
    Thanks
    0
    Thanked 0 Times in 0 Posts
    OK, you would not believe this. All of a sudden, for no apparant reason I have had to change:

    Code:
    Dim rsServices As Recordset
    to

    Code:
    Dim rsServices As DAO.Recordset
    Honestly, What tha? Why after months of running (on multiple computers) would it suddenly need this changed (on all computers)? Sometimes, I wonder if MS are just playing pratical jokes on us.

    Anyway, hope this helps anybody else in this situation.

    Ciao
    toncc

  4. #4
    Super Moderator
    Join Date
    Jun 2002
    Location
    Mt Macedon, Victoria, Australia
    Posts
    3,993
    Thanks
    1
    Thanked 45 Times in 44 Posts
    There are DAO and ADO recordsets (and Databases) so it is good practice to always declare

    Dim rs as DAO.Recordset
    Dim db as DAO.Database

    So it seems that something changed so that an unqualified recordset was treated as an ADO recordset rather than a DAO one.
    Regards
    John



  5. #5
    5 Star Lounger AndrewKKWalker's Avatar
    Join Date
    Apr 2001
    Location
    Cambridge, UK
    Posts
    1,020
    Thanks
    0
    Thanked 3 Times in 3 Posts
    I completely concur with John on this point (not that I don't always).
    Since the introduction of the ADODB as the default for Recordsets in I believe Access 2000
    It has really been a requirement to declare object variables of this type with their Library type.
    You could get the same issue with Fields and Parameters etc
    Andrew

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •