64 bit

[Roger]

Hi all
As there will be both 32 and 64 bit versions of Access 2010, do you think
Microsoft will provide a means of using Access database files from 64 bit VB
2010 programs? At present I believe the only method is to set the target CPU
to x86 in the advanced compiler settings so that the program will run in the
WOW 32 bit environment in which either oledb or the 2007 Office System Driver
can be used to read/write data to Access database files.

We have over 2,000 users of our VB suite of programs which use Access
databases. The databases are single user but, as this is a CAD application,
we now want to take advantage of the 64 bit version of Windows 7. Some users
often need to create database reports and this is one reason why Access is
better for us than SQL Server Compact Edition. Moreover while SQL Server
Compact Edition is billed as an “embedded database engine for Windows desktop
applications†it doesn’t seem to be receiving much enthusiastic support from
Microsoft or developers. Therefore, if no 64 bit option is likely to become
available for Access, I guess we may have to consider other alternatives.

Many thanks
Roger Billsdon

 

[Douglas J. Steele]

Even if I did know, I wouldn't be able to tell you before it's officially
announced, but I'd suspect that the answer will be Yes.

 

[David W. Fenton]

We have over 2,000 users of our VB suite of programs which use
Access databases

Don't you mean that you use Jet/ACE databases? You're not using them
as anything but a data store, right, so Access is not involved in
any way (though you may use Access to create them, of course).

 

[Roger]

Don't you mean that you use Jet/ACE databases? You're not using them

as anything but a data store, right, so Access is not involved in
any way (though you may use Access to create them, of course).

Hi David
Many thanks for pointing out my semantic inaccuracy. We and our users do use
Access for some work such as producing reports but, as you correctly say, as
far as our VB programs are concerned the files are simply a data store and
Access is not involved.

However, my question remains: "do you think Microsoft will provide a means
of using Access database files from 64 bit VB programs?" At present I believe
the oldedb dataprovider for JET and the 2007 Office System Driver can only be
run in the WOW 32 bit environment.
Best regards
Roger

 

[vanderghast]

While a 64bits apps cannot call directly a 32bits 'procedure', in its code,
I don't see why 64 bits app cannot exchange data with another 32 bits
application (like MS SQL Server 2005 - 32 bits). Sure, there may be problem
using features from MS SQL Server 2008 64 bits and NOT in MS SQL Server
2005, or not in Jet, but that is a relatively trivial issue not worth of
mention. As far as exchanging data from Windows to, say, Unix (or Oracle)
works, do you se a problem from Windows 64 bits and Windows 32 bits
platforms?


Vanderghast, Access MVP

 

[Roger]

When running on a 64 bit version of Windows I would like our VB programs to
be able to take full advantage of the 64 bit environment. At present on 64
bit versions of Windows the oledb dataprovider can only be run in the WOW 32
bit environment which means the whole program has to be complied with the
target CPU set to x86. We develop computer aided design (CAD) programs which
can involve large amounts of design and 3D geometry calculations of the type
which should potentially benefit from the extra performance and memory
addressing capabilities provided by the 64 bit operating system and hardware.

SQL Server, including the compact edition, is available in both 32bit and 64
bit versions. This would be one alternative we could consider but for various
reasons I'd rather continue using the Access JET file format.

If a 64 bit dataprovider can be developed for the SQL Server Compact Edition
".sdf" file format I would have thought a 64 bit dataprovider would also be
feasible for the Access JET database file format. Or am I missing something?

Best regards
Roger

 

[vanderghast]

I doubt Office 64 bits won't be able to read Office 32 bits documents on the
same machine. So I can only imagine there will be some DAO-64bits/
ADO-64bits / ADONet-64 bits libraries that your 64 bits code will be able to
include as reference and which, for you, will be able to speak (read and
write) to the data stored by 32 bits Access. Sure, if ADONet 64 bits does
not allow you to define a connection toward an Access database, 32bits,
then, maybe we have a problem. I don't have VS 2010 (beta) on a 64 bits
machine to be able to test it.

I doubt that Jet or MS SQL Server Express would be able to handle more data
than the 2Gig max (actual limit), for some time, but I can be wrong.



Vanderghast, Access MVP

 

[David W. Fenton]

If a 64 bit dataprovider can be developed for the SQL Server
Compact Edition ".sdf" file format I would have thought a 64 bit
dataprovider would also be feasible for the Access JET database
file format. Or am I missing something?

SQL Server CE is not SQL Server. It's a completely different
database engine, and one that was very recently developed. It's far
simpler than Jet/ACE, as it doesn't support a whole host of features
that Jet/ACE has offered for a very long time. This is not intended
as a criticism of it -- it was designed for use in low-profile
environments and it is well-suited to those uses.

But comparing it to Jet/ACE is not really fair. First of all, the
Jet/ACE codebase is much, much larger than that for SQL Server CE.
It's also much more complex and far older. Anyone who has to support
legacy code knows the problems that come from that.

All that said, given that Office 2010 is going to offer a 64-bit
version, it seems quite clear to me that there will be a 64-bit ACE
shipping underneath A2010. So, it seems to that that's the timeframe
for being able to use Jet/ACE data stores with fully 64-bit apps.

I don't see that this is much of an issue. I don't have any clients
running 64-bit Windows, and I don't expect any of them to be doing
so any time soon. They wouldn't benefit from a 64-bit app and I
think the vast majority of users would not.

On the other hand, CAD is an app in a particular subset of programs
that benefit greatly from high performance, so I can certainly see
why it's important to you for your app. I'm just saying that MS's
timeline for implementing 64-bit Jet/ACE is more in line with the
general user population's needs (as represented by my clients, for
instance), than it is with user populations in need of high
performance.

I would think, given the stage the Office 2010 beta is in, that the
64-bit Jet/ACE would already be available to developers to work
with, but perhaps they leave the unbundling of that until after
64-bit Access/Office 2010 is released (which may not be at the same
time as the 32-bit versions).

Perhaps you should check MSDN for this (though I generally find the
search interface not all that helpful for questions like this). I
definitely know that I've encountered the question a lot in
discussions on StackOverflow.com, so you're not alone in wanting
64-bit Jet/ACE.

 

[David W. Fenton]

Office 32 bits documents

Documents are not 32-bit (or 16-bit, or 64-bit or 128-bit) -- only
the applications are.

I don't know for certain what that means for VBA, though.

 

[Roger]

Hi all

I've just found a number of relevant threads by searching for such keywords
as "64 bit Access" in
http://social.msdn.microsoft.com/Forums/en-US/adodotnetdataproviders/threads

Unfortunately all seem to confirm this problem and so far there is no sign
of a solution for achieving 64 bit performance with a program that needs to
use Access database files. I guess I'll wait a little longer to see if the
situation changes when Access 2010 and Visual Studio 2010 are released.

Best regards
Roger

 

[Tony Toews [MVP]]

As there will be both 32 and 64 bit versions of Access 2010, do you think
Microsoft will provide a means of using Access database files from 64 bit VB
2010 programs?

What do you mean by VB 2010 programs? VB.Net? or VB 6?

I very much doubt that MS is changing the format of the ACCDB to be 64
bit specific.

1) I can see corporations running a mixed environment of 32 bit Office
2010 and 64 bit Office applications.

2) Unless the maximum size of the ACCDB was to dramatically increase
from 2 Gb there is no reason to introduce a 64 bit ACCDB data file.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a free, convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/

 

[vanderghast]

I should have said Office-32bit documents, as in documents produced by
Office 32-bit version.

Vanderghast, Access MVP

 

[David W. Fenton]

Vanderghast, Access MVP



I should have said Office-32bit documents, as in documents
produced by Office 32-bit version.

The document format is independent of the application compilation,
so I don't know why this would be worth mentioning (in the original
context you were saying you doubted there would be any inability of
64-bit apps to open documents produced by their 32-bit counterparts,
something that seems to me to be self-evident).

 

[vanderghast]

Consider the 'default' integer. With 32 bits apps, that is int32, while it
is int64 for 64 bits. So, if the 64bits has to write back the constant
integer 10 in a document where implicitly the integer size is 32, the 64
bits app has to be aware of the fact that its internally known constant
coming from code as (int64)10 has to become (int32)10 when it is time to
write it back. That is definitively doable, but not necessary given neither
bug free. Sure, this example is about to WRITE, not to READ, but when
accessing a database, I assume the OP meant otherwise than in Read Only
mode.

Vanderghast, Access MVP

 

[vanderghast]

I am not in a position to check, but is it possible, say, for Access 95 to
directly interact with an Access 2 database without first converting the
Access 2 db? Is this not an example of a 32bit app trying to interact with a
document generated from a 16bit app (and still leaving access from the 16bit
app).

Vanderghast, Access MVP


(...)

 

[David W. Fenton]

Consider the 'default' integer. With 32 bits apps, that is int32,
while it is int64 for 64 bits. So, if the 64bits has to write back
the constant integer 10 in a document where implicitly the integer
size is 32, the 64 bits app has to be aware of the fact that its
internally known constant coming from code as (int64)10 has to
become (int32)10 when it is time to write it back. That is
definitively doable, but not necessary given neither bug free.
Sure, this example is about to WRITE, not to READ, but when
accessing a database, I assume the OP meant otherwise than in Read
Only mode.

Surely the parts of apps that interact with document files are built
at a level that is independent of what platform the applications
themselves were compiled on. Given that older versions of Word can
be easily updated to understand later file formats, it seems obvious
to me that this level of abstraction is already present.

Again, it seems to me to go without saying that file formats are
completely separate from the compile settings of the apps that
manipulate them.

 

[David W. Fenton]

I am not in a position to check, but is it possible, say, for
Access 95 to directly interact with an Access 2 database without
first converting the Access 2 db? Is this not an example of a
32bit app trying to interact with a document generated from a
16bit app (and still leaving access from the 16bit app).

No, that was not possible. The first version of Access that could
interact with previous versions of *Access* files was Access 97.

That is, of course, separate from *Jet*. Jet 2 files are still
readable by current versions of Access -- I just checked in Access
2007 and was able to link to an Access 2 data file and the data was
writable. This is not surprising, seems to me. I would expect the
same thing with 64-bit A2007, if there were such a thing, because,
again, the file formats are completely independent of the compile
settings of the app doing the editing.

The wording of your question makes me think that you've
misunderstood me somewhere -- I took you to be saying what I'd
consider to be obvious, i.e., that 64-bit apps will be able to use
documents created by 32-bit apps. I am not disagreeing in any way --
indeed, I think it's too obvious to bother mentioning.

 

[vanderghast]

And given that the table design already specify which data size it expects
(byte, (short) integer, long integer) any application trying to write in the
database may then very well know how many bits are involved, exactly.

It is obvious, yes, when you are aware of it, but maybe it is not for
everyone

Sure, as you pointed out, if the file format change, that is another level
of implications which is not necessary related to the bits used by the
processors. (Also somehow obvious)


Vanderghast, Access MVP

 

[Roger]

Hi David
Many thanks for the reply.

SQL Server CE is not SQL Server. It's a completely different
database engine, and one that was very recently developed. It's far
simpler than Jet/ACE, as it doesn't support a whole host of features
that Jet/ACE has offered for a very long time. This is not intended
as a criticism of it -- it was designed for use in low-profile
environments and it is well-suited to those uses.

But comparing it to Jet/ACE is not really fair. First of all, the
Jet/ACE codebase is much, much larger than that for SQL Server CE.
It's also much more complex and far older. Anyone who has to support
legacy code knows the problems that come from that.

I agree with your points, however, as the requirement is just to read/write
data to the data store I'd expect the level of complexity would be similar as
all the extra complexity in Access vs SQL Server CE is in other areas eg
reports, VBA, etc, etc. The program code required to process SQL statements
to read/write data to the data store in either the .sdf or the .accdb (or in
fact the .mdb) file formats surely can't be that different.

I also agree with your point about the difficulty of maintaining legacy
code. However, in my experience maintaining upwards compatibility with
previous file formats is not where the difficult problems are encountered.

Unfortunately many in the developer community tend to look down upon Access
as the poor relation to SQL Server as their efforts and those of Microsoft
seem increasingly focussed on large-scale, mulit-user enterprise and web
applications. However, for a lot of applications including ours, Access has
many advantages in relation to both SQL Server and SQL Server CE and I feel
it deserves to be better supported in .NET, Visual Studio 2010, etc.

I don't see that this is much of an issue. I don't have any clients
running 64-bit Windows, and I don't expect any of them to be doing
so any time soon. They wouldn't benefit from a 64-bit app and I
think the vast majority of users would not.

On the other hand, CAD is an app in a particular subset of programs
that benefit greatly from high performance, so I can certainly see
why it's important to you for your app. I'm just saying that MS's
timeline for implementing 64-bit Jet/ACE is more in line with the
general user population's needs (as represented by my clients, for
instance), than it is with user populations in need of high
performance.

New PCs with 4GB or more of memory are now affordable and so I think their
use may rapidly spread beyond applications such as CAD and gaming. For
example, those who need lots of different programs running simultaneously
should benefit from the extra memory particularly as new PCs are mostly
multi-core and the more recent versions of Windows have become much better at
managing multiple threads and processes. To take advantage of 4GB+ of memory,
the 64 bit versions of Windows are required. Apparently both 32 and 64 bit
versions of Office 2010 will be supplied on the same DVD and the 64 bit
version of Office will be automatically selected for installation on 64 bit
versions of Windows. Taken together I think all these factors may mean we are
near the tipping point where 64 bit Windows and programs will suddenly
increase.

Once again, many thanks for your input.

Best regards
Roger

 

[Roger]

Even if I did know, I wouldn't be able to tell you before it's officially

announced, but I'd suspect that the answer will be Yes.

Hi Doug

Many thanks for your reply. Reading between the lines, I think that might be
a yes, so the question might be when rather than if!

Best regards
Roger