From: Albert D. Kallal on
"David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message

>> but for office 2010, you
>> can NOT mix parts or 32/64. So, you can't install excel 32 and
>> then install excel 64 from the same version of office.
>
> Hmm. That's not what Office Watch is saying:
>
> Installing Office 2010 64-bit
> http://news.office-watch.com/t/n.aspx?a=1404
>
> Make sure any Office add-ins, connectors, COM DLL's etc that you
> rely on are explicitly stated as being Office 2010 and 64-bit
> compatible.
>
> You have to uninstall any 32-bit version of Office that's on the
> computer. The 64-bit installer won't convert or upgrade an
> existing Office installation.


I think they forgot to add the above that they are talking about a upgrade
here. Just like a standard install of office asks you to upgrade and delete
the previous version. The above says you have to remove the previous version
and that makes sense. However, if you choosing a custom install then you can
keep previous versions. To my knowledge nothing is stopping one from
installing access 97, 2000, 2003 like before. The ONLY new issue would be
that of shared code libraries in the SAME version of office such as VBA,
spell checking etc. That's why you can't mix/match the SAME version of
office. So the above is correct in telling you that the 64 office can't be
used to upgrade a previous versions, but with a custom install, the above is
incorrect to my knowledge.

>
>> If you deploying accDB, or mdb, then it should run find on
>> access(32) or 64 (even for runtime). However, for a accDE, you
>> have to pre-compile it and you have to do so on the correct os
>> version of 32 or 64 bits.
>
> This means 4 variations if you are supporting both 32/64-bit Windows
> and 32/64-bit Access.
>

True, while it is 4 variations, the office(32) runs equally well on 32 or 64
bit machines and that is only thus one accDE(32) and one setup to supply for
office(32). I will not matter if the os is 32 or 64, it only matters about
the version of office being 32 or 64. So, it is 4 variations, but it is only
two versions of the accDE needed to cover those 4 cases..


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal(a)msn.com


From: The Frog on
Okay, so there's lots on the plate when considering 64bitedness! It
seems that the consensus is that a 64bit OS is a good thing, but wait
on the 64bit software unless absolutely necessary. Hardware should
support full virtualisation, and dont limit yourself on the RAM. Seems
fair enough.

The question then becomes - assuming Win7 64 bit OS and Office 2010 32
bit - how does one compile an accDE 64bit for a 64bit client? You
would need to have another machine with a separate install of Access
it would seem. Or just ship the app uncompiled. I prefer to compile,
but that is just a preference of mine. The company I work for has the
uncompiled version anyway so there is no code 'protection' (I dont buy
that argument anyway, if you have a strong enough inclination you can
'roll your own' anything in Access anyway), I just use it to stop
users play playing.

Does anyone know if you could install a 32bit runtime on a system that
has 64bit Office? That would eliminate most of the hassles right
there.

Cheers

The Frog
From: kgander on
On Apr 13, 2:23 pm, "David W. Fenton" <XXXuse...(a)dfenton.com.invalid>
wrote:
> kgander <kgande...(a)gmail.com> wrote innews:2acc278d-cade-49a3-9154-e6021fbacc2d(a)z11g2000yqz.googlegroups.co
> m:
>
> > For a new 64-bit PC where you'll regularly run software in XP
> > Mode, it's best to make sure it supports hardware virtualization.
> > Hardware virtualization isn't required, but it should run XP Mode
> > substantially faster.  My guess the same is true for WOW64
> > (Windows7's 32-bit emulation layer).
>
> > Microsoft has a free Hardware-Assisted Virtualization (HAV)
> > Detection Tool you can download from their website.
>
> I would assume that all new hardware is going to support it. It's
> rather hard to run a tool on a computer you don't have in front of
> you, of course.

True, but there will be plenty of non-HAV PCs for a while, so it's
good to know how to avoid them. And if I were specing machines
out for a client, I'd make sure they knew about this limitation in
advance. It's not something PC sales people will point out.

> I'm not big on upgrading Windows, but Win7 is the first in a long
> time that I'd recommend it. I've done it for a 7-year-old Thinkpad
> laptop and it's been a huge win, faster than the previous WinXP, in
> fact. But, of course, that's 32-bit, not 64-bit, and the memory
> recommendations are irrelevant, and it has only 1.5GBs of RAM, so I
> don't think running a virtual machine is a practical option.

That's very encouraging to hear.
From: David W. Fenton on
"Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in
news:1G5xn.514$0_7.337(a)newsfe25.iad:

> "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message
>
>>> but for office 2010, you
>>> can NOT mix parts or 32/64. So, you can't install excel 32 and
>>> then install excel 64 from the same version of office.
>>
>> Hmm. That's not what Office Watch is saying:
>>
>> Installing Office 2010 64-bit
>> http://news.office-watch.com/t/n.aspx?a=1404
>>
>> Make sure any Office add-ins, connectors, COM DLL's etc that
>> you rely on are explicitly stated as being Office 2010 and
>> 64-bit compatible.
>>
>> You have to uninstall any 32-bit version of Office that's on
>> the computer. The 64-bit installer won't convert or upgrade an
>> existing Office installation.
>
> I think they forgot to add the above that they are talking about a
> upgrade here. Just like a standard install of office asks you to
> upgrade and delete the previous version. The above says you have
> to remove the previous version and that makes sense. However, if
> you choosing a custom install then you can keep previous versions.
> To my knowledge nothing is stopping one from installing access 97,
> 2000, 2003 like before.

I think the Office Watch folks are clever enough to know about that
already. They are clearly saying you can't have 64-bit Office
installed on a system with any 32-bit version of Office. I can't
read what they are saying the way you're interpreting it.

> The ONLY new issue would be
> that of shared code libraries in the SAME version of office such
> as VBA, spell checking etc. That's why you can't mix/match the
> SAME version of office.

Office Watch is not saying just that. They are saying no mixing of
32- and 64-bit in any version.

> So the above is correct in telling you that the 64 office can't be
> used to upgrade a previous versions, but with a custom install,
> the above is incorrect to my knowledge.

I think the use of "upgrade" is problematic, given that Office 2010
has no upgrade version/pricing, but I know what you mean.

>>> If you deploying accDB, or mdb, then it should run find on
>>> access(32) or 64 (even for runtime). However, for a accDE, you
>>> have to pre-compile it and you have to do so on the correct os
>>> version of 32 or 64 bits.
>>
>> This means 4 variations if you are supporting both 32/64-bit
>> Windows and 32/64-bit Access.
>
> True, while it is 4 variations, the office(32) runs equally well
> on 32 or 64 bit machines and that is only thus one accDE(32) and
> one setup to supply for office(32).
> I will not matter if the os is 32 or 64, it only matters about
> the version of office being 32 or 64. So, it is 4 variations, but
> it is only two versions of the accDE needed to cover those 4
> cases..

Hmm. What about ACCDE/MDE that has API calls to Windows DLLs? Won't
that be a problem? Or is that entirely "late bound" so that it
doesn't change the compiled result?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on
The Frog <mr.frog.to.you(a)googlemail.com> wrote in
news:019e6cae-ed43-4360-b512-83470baeb18b(a)z11g2000yqz.googlegroups.co
m:

> The question then becomes - assuming Win7 64 bit OS and Office
> 2010 32 bit - how does one compile an accDE 64bit for a 64bit
> client? You would need to have another machine with a separate
> install of Access it would seem. Or just ship the app uncompiled.
> I prefer to compile, but that is just a preference of mine. The
> company I work for has the uncompiled version anyway so there is
> no code 'protection' (I dont buy that argument anyway, if you have
> a strong enough inclination you can 'roll your own' anything in
> Access anyway), I just use it to stop users play playing.

I would assume that you would start with a 64-bit Windows and
install Office 32-bit, and run a virtual machine with 64-bit Windows
on which you'd install the 64-bit Office. I believe this is
something that one of the Office Watch articles suggests explicitly.

You could choose to go the other route, i.e., install 64-bit Windows
on your host 64-bit Windows and install the 32-bit version in your
VM, but I think I'd likely choose the version for my daily work
(i.e., what I install in the host OS) that I'm going to be deploying
in, and for now, that means the first scenario, with 32-bit in the
host OS and 64-bit in the VM.

> Does anyone know if you could install a 32bit runtime on a system
> that has 64bit Office? That would eliminate most of the hassles
> right there.

I'd assume so, given that the runtime is just Access with a few
different registry keys.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10
Prev: Problem with query
Next: Append Query error with apostrophe