Full Version: Recordset Type Mismatch
UtterAccess Forums > Microsoft® Access > Access Forms
I have an application, with both front and back end databases, that uses the following code (which I do not understand) for Recordsets.
Dim conDatabase As ADODB.Connection
Dim rstPlacings As ADODB.Recordset

Set conDatabase = CurrentProject.Connection

mySQL = “ Select …….”
Set rstPlacings = New Recordset
rstPlacings.Open mySQL, conDatabase, adOpenDynamic, adLockOptimistic


Set rstPlacings = Nothing
Set conDatabase = Nothing
This works well in both .mdb and .mde formats on my desktop PC where it was created.
When the .mde databases are loaded to the laptop PC I get the error message “Type Mismatch” which I have tracked down to the initiated by the code “ Set conDatabase = CurrentProject.Connection “.
I do not get this error when it is in the .mdb format or when it is converted to .mde format on the laptop.
It would appear as if there is a difference in the setup of the PCs.
How do I set up the laptop to avoid this problem?
Thanking you in anticipation.
Open up the VBA window on the laptop and look at the References. There's most likely an issue with ADO not being selected, or improperly installed.
If it's not the ADO references, then have a look as the line
Usually someone that has developed using ado connections, rather than ODBC will have option explict set.
In which case, if ADO is not in the references, I'd expect the code to error each time it runs, syaing that it doesn't understand the DIM statments.
This is only a guesss, but it could be that the connection has been made using drive mappings rather than urn IP addresses, and that you laptop does not have the same mapping as the machines on which the code works.
Thankyou for your replies, but you must excuse my ignorance.
irstly, I had a look at the References but did not know what was expected.
Both PCs have these four selected:
• Visual Basic for Applications
• Microsoft Access 11.0 Object Library
• OLE Automation
• Microsoft ActiveX Data Objects 2.1 Library
There are two ADO References in the list, should either or both of these be selected?
• Microsoft ADO Ext. 2.8 for DDL and Security
• Microsoft ADO Ext. 6.0 for DDL and Security
Secondly, I have been led to believe that mapping related to networked PCs.
These are not networked. Both the front and back end are on the same PC.
I want to point out that adOpenDynamic is not supported and therefore what is actually happening is that ADODB substitutes the request with closest matching recordset type (likely but not necessarily adOpenStatic).
Also, I want to ask - is either of your PC a Windows 7? If so, was SP1 installed? There is a known issue where application compiled on Win 7 SP 1 will break on any other OSes.
My desktop is using Win 7 where as the laptop is XP.
believe SP1 was installed. I have the disks and can reload if it is considered that may be the problem.
I'd agree with the Win 7 SP1 issue. It's just gotta be that. (Still can't believe it. Shaking my head months later!)
FWIW I'd say that if this is an ADP (which it doesn't sound like) then your CurrentProject.Connection is inherently client side. Otherwise - it's Server side by default.
In which case, a KeySet cursor type would be more likely to be returned than a Static. (But B's right, the substitution would be made.)
Thanks guys for you knowledgeable feedback but unfortunately most of this has gone right over my head.
I am no closer to resolving the problem.
Here's some background information; you'll perhaps want to follow some links.
o put it in practical terms, your options are:
1) Use DAO. IMHO, there is very little reason to use ADO with Access back-end; it's definitely an interesting asset when we're using different backend but if it's Access, then DAO really is better.
2) Upgrade all of your machine to Win 7 SP1. Not always feasible.
3) Do not develop on Win 7 SP1 anymore. If you want to make design changes to your file, you have to use some other machine that isn't Win 7 SP1. That way, it will run on any machines (including ones with Win7 SP1). Right now, if you already made changes, then you may need to take your files to the other machine and use /decompile switch which I believe (but haven't done myself) will allow you to remove the incompatible code and let you start afresh.
Perhaps a simple oversight, but you are ensuring that the 'copied' BE is present and correct on the laptop in exactly the same location as the dev pc (or that all tables are re-linked successfully). I am not familar with the error messages thrown up by such mistakes so perhaps you get a different message but just thought I'd throw it out there.
Just browsed though the background information link mentioned by BananaRepublic; very interesting.
know why the problem exists and not resolved. Thanks Microsoft.
I will be making the MDE files on the laptop with XP.
Thanks everyo
This is a "lo-fi" version of UA. To view the full version with more information, formatting and images, please click here.