Access VBA and its cryptic error messages eh? Run-time error '13': Type mismatch is probably not unfamiliar to most Access aficionados. And to be fair, it even makes sense semantically. If you're mucking up your data types, you'll see it. If you're foolish enough to try and use numbers where strings are needed, booleans where dates are required and so on, you're asking for it.

Where it can become cryptic is in some of the object libraries, especially when two or more libraries have objects with the same name. A very common example of this is a Recordset.

More recent versions of Access have two ways of dealing with data in VBA; ADO and DAO. ADO is newer and more portable. DAO is older (but still present despite talk of deprecation) and probably quicker and easier to use in Access-only applications. Nonetheless, it is possible to convert your DAO to ADO if you want to be ready for the "future of data access". Ahem.

The problem is that both ADO and DAO have an object called "Recordset". This object stores a big ermmm...set of records, to let you manipulate them programmatically. You can prepare one for use in VBA via:

If you have either the DAO libraries or the ADO libraries loaded as references into your VBA project (to check this, choose the Tools menu in the VBA editor, then References. If "Microsoft DAO 3.6 Object Library" is ticked, that's the DAO one, if "ActiveX Data Objects 2.x Library" is ticked, that's ADO), then you get a recordset of the appropriate type. Great.

Not so great is if you have both loaded so get a random type of recordset, or the wrong one. Why the problem? Well, they're both called Recodset, but you can do different things with them. An example:
Set rs = CurrentDb.OpenRecordset(...) only works with a DAO recordset. If you're using an ADO one, you'll get the dreaded "Run-time error '13': Type mismatch".

The solution? Well, if you're only using either DAO or ADO, make sure youhave the correct, and only the correct reference ticked under the Tools -> References menu described above. Better yet, and to futureproof your code against some fool ticking the wrong box, explicitly declare what sort of recordset you want in one of the two following ways as appropriate:

Yes, it's more typing but these extra few letters allow you a) to use both ADO and DAO in one application if you really want do, and b) remove the chance that VBA will give a type of recordset you don't want. Be explicit.