64 bit

[Roger]

Hi Tony

Many thanks for your reply.

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

Sorry for the naming confusion. While the first .NET version of VB (the one
launched after VB6) was generally known as VB.NET there doesn't seem to have
been a widely agreed name for the subsequent versions launched with Visual
Studio 2003, 2005 or 2008. Some refer to VB2008 as VB9, but in the Visual
Studio "Help>About Microsoft Visual Studio" menu option it gives the product
detail as "Microsoft Visual Basic 2008" Visual Studio 2010 is to launch on 22
March 2010 and so I used the name VB 2010.

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.

I agree corporations will probably use a mix of 32 and 64 bit versions of
Windows and the Office applications and this is one reason why I expect the
file format will be the same for both versions. There's no reason why both 32
and 64 bit programs cannot read and write to the same file format.

The reason for wanting to use a 64 bit program to read/write Access files is
not related to the 2GB file size, rather it's so the program can benefit from
the extra memory addressing capability for calculations, in-memory data
handling and 64 bit interfaces to other programs. CAD applications,
especially 3D, often involve complex calculations operating on large amounts
of data and we're always being asked to increase performance. To use the
current JET and ACE 32 bit dataproviders the whole program has to be
targetted at x86 CPU so that it will run in the WOW 32 bit environment and
thus limit it's performance.

I hope this helps, explain the situation a little better.
Best regards
Roger

 

[David W. Fenton]

[quoting me:]

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....

Re-read my message. I didn't mention Access. I compared Jet/ACE to
SQL Server CE, which means comparing two database engines only.

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.

This point is entirely irrelevant as the comparison is between the
database engines, not between Access and something else.

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

These people are mostly ignorant.

It's been quite amusing posting on StackOverflow over the last year.
When I started posting there, a number of anti-Access bigots were
having their say and I stepped in and pointed out the errors in
their assertions. At least one of the Access critics has since
admitted, after actually trying out Access firsthand, that it's a
pretty amazing application, both as development tool and as database
engine, i.e., Jet/ACE.

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.

Microsoft is actually investing quite a bit in Access again starting
with A2007. However, it's not clear to me that the work going into
the ACE is for the purpose of making Access better or simply in
support of Sharepoing. For instance, all of the new data types in
A2007 were implemented for compatibility with Sharepoint
(multi-value fields, attachment fields, and the append-only memo
fields).

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.

You won't get any arguments from me on that.

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.

But 64-bit Vista already exists and already offered that extra
memory. If 32-bit apps are compiled correctly, the OS can let them
take full advantage of up to 4GBs of memory each, if running in
64-bit Windows. That is, the OS virtualizes memory for the app and
gives it up to the full 4GBs of memory that is addressable with
32-bits.

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.

Office 2010 is also going to take care of your need for 64-bit
Jet/ACE, surely.

 

[Tony Toews [MVP]]

It's been quite amusing posting on StackOverflow over the last year.
When I started posting there, a number of anti-Access bigots were
having their say and I stepped in and pointed out the errors in
their assertions. At least one of the Access critics has since
admitted, after actually trying out Access firsthand, that it's a
pretty amazing application, both as development tool and as database
engine, i.e., Jet/ACE.

Yes, it's been a lot of fun posting there. One person had a posting
with about six points on it. I rebutted each one of his postings
showing that he clearly had never used Access to any great extent.
He then deleted his posting along with all my comments. That really
irritated me. Grrrrr.

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/

 

[Tony Toews [MVP]]

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.

CAD and graphics folks were likely early adapters of Vista 64 bit
edition even if they were running in 32 bit mode.

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.

Well, other than running Virtual PC I seldom exceed 1 Gb of RAM in
regular usage. Now granted I'm not a gamer. So I don't think most
folks need more than 2 Gb. Nevertheless RAM is cheap so what the heck.

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/

 

[Tony Toews [MVP]]

The reason for wanting to use a 64 bit program to read/write Access files is
not related to the 2GB file size, rather it's so the program can benefit from
the extra memory addressing capability for calculations, in-memory data
handling

I can't see that being a reason. Access apps seldom exceed 50 Mb in
size.

and 64 bit interfaces to other programs. CAD applications,
especially 3D, often involve complex calculations operating on large amounts
of data and we're always being asked to increase performance.

Yup, no problem there.

To use the
current JET and ACE 32 bit dataproviders the whole program has to be
targetted at x86 CPU so that it will run in the WOW 32 bit environment and
thus limit it's performance.

I don't see 32 bit to 64 bit being a performance enhancer other than
for specialized users such as CAD or graphics or similar who truly
need more than 3 Gb of RAM.

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/

 

[David W. Fenton]

Yes, it's been a lot of fun posting there. One person had a
posting with about six points on it. I rebutted each one of his
postings showing that he clearly had never used Access to any
great extent. He then deleted his posting along with all my
comments. That really irritated me. Grrrrr.

Well, as much as I appreciate and sympathize with your irritation,
to be honest, it seems to me that for SO to accomplishes its stated
purpose, it's actually better for a completely erroneous post to be
deleted rather than to be corrected in comments. If the OP doesn't
want to correct the post, I think it's likely best that the post
just gets deleted, even if it does take with it the gems you
included in the comments.

I hoped you got to vote the post down before it was deleted so that
it dinged the poster's reputation. I don't know if that goes away
when a post is deleted or not.

 

[David W. Fenton]

I don't see 32 bit to 64 bit being a performance enhancer other
than for specialized users such as CAD or graphics or similar who
truly need more than 3 Gb of RAM.

But I think his point is that a CAD program needs the resources, but
the data store he's chosen, Jet/ACE, is placing limits on how
efficient the app can be, since it can't be compiled as pure 64-bit
because of the Jet dependency. That is, the performance issue is not
in the database, but elsewhere, but the 32-bit limitation of the
database engine means the other parts of the app can't take full
advantage of the available resources on 64-bit Windows.

 

[Roger]

Hi David

But I think his point is that a CAD program needs the resources, but
the data store he's chosen, Jet/ACE, is placing limits on how
efficient the app can be, since it can't be compiled as pure 64-bit
because of the Jet dependency. That is, the performance issue is not
in the database, but elsewhere, but the 32-bit limitation of the
database engine means the other parts of the app can't take full
advantage of the available resources on 64-bit Windows.

Many thanks for this clarification which I think makes the position
absolutely crystal clear.

Best regards
Roger

 

[vanderghast]

You may get some interesting comments from the Visual Studio team about "Why
there is no 64 bit version? " (of Visual Studio) at
http://blogs.msdn.com/ricom/archive/2009/06/10/visual-studio-why-is-there-no-64-bit-version.aspx

While some points are specific to VS, many are general enough to be
applicable to a large number of applications, and has a section about Office
(and even mentions Access!).

It is undeniable that ACAD like applications doing a lot of 64 bit math have
a strong point to move to 64 bits.


Vanderghast, Access MVP