Here's another bizarre 'error' that I stumbled upon. A guy by the name of Hellion found the 'solution.'
MS is killing us with this stuff.
Here's what I finally found out that appears to be relevant:
On 64-bit Windows 7 Pro, the Microsoft MDAC Component Checker tool tells me that I am running MDAC version "UNKNOWN", with file versions of either 6.1.7600.16385, or 6.1.7601.17514 (which by a strange coincidence match up very closely with the Windows
version number). On 32-bit Windows XP, on the other hand, Component Checker says I'm running version "MDAC 2.8 SP1 ON WINDOWS XP SP3", with file versions of 2.81.1132.0 or 2.81.3012.0, which look like proper MDAC version numbers.
If I change the "broken" code while I'm on XP and thereby force a recompile, the exact same code that produced the run-time error (either the type mismatch 13 error mentioned above, or a run-time error 430) will start working (and keep working when I copy
it around to other XP boxes, or to my Windows 7 box). If I change the code on my Windows 7 box and redistribute that to an XP box, it breaks, despite the fact that every reference in the list of references is identically named, and points to an identical file
in an identical disk location.
Edit: Apparently this version numbering is due to Windows Vista/7 using "WDAC" instead of "MDAC", and the specific problem of code compiled on Win7 SP1 being broken when run on downlevel OSes is a known issue, referenced at support.microsoft.com kb article
2517589 and at this post on technet. Switching to late binding, installing a KB fix on the downlevel systems, or linking in "back-compatible" versions of ADO are the suggested fixes.
Edit 2: The fix that I have settled on at this point is to go ahead and do all my development work (with early binding) on my Win7SP1 box, and then recompile the whole app on a WinXP box before deploying it to my users.