ac07 64 Bit problems with ADO references

[hydroparadise via AccessMonster.com]

I have a .accdb file that was create using Access 07 32 bit (ac07 x86) that
uses some ADO procedures that I would like to share with some of my
colleagues on a shared network drive. A couple of them that have the 64-bit
version of of Access 07 (ac07 x64). Of course, all sorts of reference errors
arrise when the file is opened using ac07 x64, but is easily resolved by
repointing the reference to Microsoft's ActiveX Data Access using ac07 x64.
Conversely, ac07 x86 has the same problems after the reference change in ac07
x64. Is there a smoother way of dealing with this situation? Hoping there
might be a VBA to point to the right refference depending on which version of
Access is being opened.

 

[Tom van Stiphout]

On Tue, 19 May 2009 19:36:27 GMT, "hydroparadise via

There is no 64-bit version of any Office 2007 product.

-Tom.
Microsoft Access MVP

 

[david]

Apart from what Tom said, if you are having ADO reference problems,
you could consider removing the ADO reference. It's not really
required, it just makes things easier.

The ADO reference is only required to get the Type Library. The
Library gives you the names you can use in Declarations, and the
values of the Constants. (The same is true of the DAO reference)

The actual ADO code is linked in to Access anyway:
you can get at any kind of ADO object or method starting from
the connection property of the application object, or using
CreateObject for other data sources.

You just have to declare all your ADO objects as "object",
and work out the value of any constants you use.

(david)

 

[hydroparadise via AccessMonster.com]

I'm sorry, I think think I mispoke. I ment the opperating system (32 bit vs
64 bit). What exactly happens is that Access comes up franticly looking for
a .dll file (cant get remember the name, something like adows**.dll or
something like that). I end up having to go to the vb editor, then
references and rereference what I mentioned earlier. This is what Im calling
refferencing problems. Also, it was my assumption that at least some Office
2007 components were 64 bit only process in respect to the opperating system
because of the directory its stored in (ie Vista's Program Files vs Program
Files x86)

There is no 64-bit version of any Office 2007 product.

-Tom.
Microsoft Access MVP

I have a .accdb file that was create using Access 07 32 bit (ac07 x86) that
uses some ADO procedures that I would like to share with some of my

[quoted text clipped - 6 lines]

might be a VBA to point to the right refference depending on which version of
Access is being opened.

 

[hydroparadise via AccessMonster.com]

Not clear how this works... I'm fairly vebose in VBA, but am not an expert.
I suppose what you mean is instead of,

Dim rs As ADOBD.Recordset
Set rs = New ADODB.Recordset

It would look something like,

Dim rs As Object
Set rs = CreateObject("ADODB.Recordset")

And if Im following you right, I should be able to use this an ADO Recordset
whether or not its referenced or not?

BTW, thanks for you guys inputs

Apart from what Tom said, if you are having ADO reference problems,
you could consider removing the ADO reference. It's not really
required, it just makes things easier.

The ADO reference is only required to get the Type Library. The
Library gives you the names you can use in Declarations, and the
values of the Constants. (The same is true of the DAO reference)

The actual ADO code is linked in to Access anyway:
you can get at any kind of ADO object or method starting from
the connection property of the application object, or using
CreateObject for other data sources.

You just have to declare all your ADO objects as "object",
and work out the value of any constants you use.

(david)

I have a .accdb file that was create using Access 07 32 bit (ac07 x86) that
uses some ADO procedures that I would like to share with some of my

[quoted text clipped - 12 lines]

of
Access is being opened.

 

[vanderghast]

When Access 2007 (or 2003) works under Vista 64 bits, it runs as a 32 bits
app.


Further more, the VBA code running from Access is still 32 bits and is
likely unable to handle any 64 bits code you would throw at it, so the
references, if some are required, SHOULD be 32 bits dll. As example:
Microsoft ActiveX Data Objects 2.1 Library (C:\Program Fiels (x86)\Common
Files\System\ado\msado21.tbl)



Vanderghast, Access MVP

I'm sorry, I think think I mispoke. I ment the opperating system (32 bit
vs
64 bit). What exactly happens is that Access comes up franticly looking
for
a .dll file (cant get remember the name, something like adows**.dll or
something like that). I end up having to go to the vb editor, then
references and rereference what I mentioned earlier. This is what Im
calling
refferencing problems. Also, it was my assumption that at least some
Office
2007 components were 64 bit only process in respect to the opperating
system
because of the directory its stored in (ie Vista's Program Files vs
Program
Files x86)

There is no 64-bit version of any Office 2007 product.

-Tom.
Microsoft Access MVP

I have a .accdb file that was create using Access 07 32 bit (ac07 x86)
that
uses some ADO procedures that I would like to share with some of my

[quoted text clipped - 6 lines]

might be a VBA to point to the right refference depending on which
version of
Access is being opened.

 

[egerds]

How To Do 64-bit Arithmetic in VBA
http://support.microsoft.com/kb/189862

 

[vanderghast]

Someone can also use the cryptography API, and be able to work with 128, if
not 256 bits or more. Can also use decimal value ( CDec( ) ).

The article seems wrong on an important point: the sign is the first bit,
but that sign will NOT be perceived correctly by low value part, niether the
first bit of low value will be correctly read as NOT being a bit sign, when
read as integer (since VBA does not handle unsigned integers).


Example, with 4 bits read as 2 two bits integers (instead of 64 bits read as
two 32 bits integers).


0111

is the value 7, but

high value = 01 is 1

and

low value = 11 is -1

(VB/VBA do not handle unsigned integers, so the first bit is necessary the
sign bit)


and so 4 * high + low = 3, incorrect, should be 7.



Vanderghast, Access MVP

 

[david]

Yes, that's right.

The other thing is that if you want a recordset from a linked table, you can
do something like this:

dim rs as object
set rs = application.codedb.openrecordset(....)

dao example because I know dao.

For adodb recordsets from the current database you start with something
sort of like this?
dim rs as object
set rs = application.currentconnection.whatever


(david)

Not clear how this works... I'm fairly vebose in VBA, but am not an
expert.
I suppose what you mean is instead of,

Dim rs As ADOBD.Recordset
Set rs = New ADODB.Recordset

It would look something like,

Dim rs As Object
Set rs = CreateObject("ADODB.Recordset")

And if Im following you right, I should be able to use this an ADO
Recordset
whether or not its referenced or not?

BTW, thanks for you guys inputs

Apart from what Tom said, if you are having ADO reference problems,
you could consider removing the ADO reference. It's not really
required, it just makes things easier.

The ADO reference is only required to get the Type Library. The
Library gives you the names you can use in Declarations, and the
values of the Constants. (The same is true of the DAO reference)

The actual ADO code is linked in to Access anyway:
you can get at any kind of ADO object or method starting from
the connection property of the application object, or using
CreateObject for other data sources.

You just have to declare all your ADO objects as "object",
and work out the value of any constants you use.

(david)

I have a .accdb file that was create using Access 07 32 bit (ac07 x86)
that
uses some ADO procedures that I would like to share with some of my

[quoted text clipped - 12 lines]

of
Access is being opened.