[AccessD] Variable data type for holding ADODB.recordset RecordCount on MS Access 64 bit

Tue Feb 9 16:22:55 CST 2021

Thanks for reaching out.
Rocky, we are using ADO for certain work with the SQL server backend.
Jim, thanks for the old archived post.
>From reading that and a few other links I understand that the old ADO 2.8
library (msado28.tlb) supports both 32bit and 64bit.
And that the ADO 6.1 library (msado15.dll) is the ADO library with the
latest feature set supporting both  32bit and 64bit applications.

We are using only a minor subset of the ADO feature set and could probably
go on using the ADO 28 library that has been around for the past many years.

With the old ADO 2.8 type library referenced in VBA I had a closer look in
the VBA object browser using Office 32 bit.
The file sits in C:\Program Files (x86)\Common Files\System\ado\
(and with an identical file  - actually all files in the ado folder appears
to be exactly the same in C:\Program Files\Common Files\System\ado\ )

The RecordCount property in the ADO.Recordset class is an ADO_LONGPTR type.

So in Office 32 bit we can use a long variable and when upgrading the
Access app to be compatible with Office 64 bit we need to make that same
variable a LongPtr type.
The app then compiled at that point.
Suffice to say we've got the app compiled to run in Office 64 bit.

Will update the MS Access app to reference the ADO 6.1 (msado15.dll) as the
latest type library and abandon the old 2.8 library.

thanks,
/borge

On Mon, 8 Feb 2021 at 11:12 pm, Jim Dettman via AccessD <
accessd at databaseadvisors.com> wrote:

>
> I remember when this broke, but I don't remember the particulars as I was
> using DAO mostly.
>
> This all should have been patched up however at this point, so I believe
> it's a matter of selecting the right lib (6.1) and re-compiling.
>
> The original blog post on the problem can be found here:
>
>
> https://web.archive.org/web/20120331232037/http://blogs.msdn.com/b/psssql/ar
> chive/2011/10/03/yes-we-made-a-mistake-and-are-finally-going-to-fix-it.aspx
> <https://web.archive.org/web/20120331232037/http://blogs.msdn.com/b/psssql/archive/2011/10/03/yes-we-made-a-mistake-and-are-finally-going-to-fix-it.aspx>
>
> HTH,
> Jim.
>
> -----Original Message-----
> From: AccessD On Behalf Of Rocky Smolin
> Sent: Monday, February 8, 2021 1:15 AM
> To: Access Developers discussion and problem solving
> <accessd at databaseadvisors.com>
> Subject: Re: [AccessD] Variable data type for holding ADODB.recordset
> RecordCount on MS Access 64 bit
>
> is ADO a requirement?  I've always found DAO to be much easier to work with
> and seems faster in many cases.
>
> Not the help you're looking for I know. But I tried ADO years ago and never
> went back to it.
>
> r
>
> On Sun, Feb 7, 2021 at 9:35 PM Borge Hansen <pcs.accessd at gmail.com> wrote:
>
> > Help!
> >
> > We are converting a fairly large Access app to run in Office 64 bit
> > environment.
> > We have modified all Functions to PtrSafe.
> >
> > We are now debugging / compiling the app and identifying variables to
> have
> > to be set to LongPtr to play along with the PtrSafe API functions.
> >
> > We ran into a 'type mismatch' issue like this:
> >
> > lngTotal = rs.recordcount
> > for an ADODB.recordset
> >
> > There is long support article at Microsoft, talking about ADO using
> > longlong datatype on 64 bit systems which causes problems with
> applications
> > using variables with Long data type
> >
> >
> >
>
> https://support.microsoft.com/en-us/topic/-type-mismatch-error-message-when-
>
> you-run-a-vba-macro-in-a-64-bit-version-of-an-office-2010-application-ba8aae
> 20-0762-4108-93de-1787f6e09076
> <https://support.microsoft.com/en-us/topic/-type-mismatch-error-message-when-you-run-a-vba-macro-in-a-64-bit-version-of-an-office-2010-application-ba8aae20-0762-4108-93de-1787f6e09076>
> >
> > It talks about applying a hotfix for your particular issue.
> > The article appears to be several years old.
> >
> > We want to be able to run the converted app in both 32 bit and 64 bit.
> >
> > Is it a matter of just referencing another ADO library - and if so which
> > one? - or do we also need to apply conditional compile arguments for the
> > scenario
> > dim lngTotal as long
> > lngTotal = rs.recordcount
> >
> > We have been using
> > Microsoft ActiveX Data Objects 2.8 Library  (msado28.tlb)
> > for the past ten years or more.
> >
> > We are compiling using MS Access 2019 on a Windows 10 VM with latest
> > updates
> >
> > Anyone who can help with this??
> >
> > ???
> >
> > /borge
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > https://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> https://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> https://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>