"Bob Barrows" <reb01501 (AT) yahoo (DOT) com> wrote in
news:wVJ3o.15321$Zp1.13486 (AT) newsfe15 (DOT) iad:

Yes, indeed you were! I didn't make the context switch to
server-side, so read IE instead.

My apologies!

That is correct. It's exactly the same as with IE, though -- you're
running an IIS executable that is compiled for 32-bit as opposed to
the different IIS executable that was compiled for 64.

No, just your garden-variety confusion!

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

On Jul 27, 3:13*am, "David W. Fenton" <NoEm... (AT) SeeSignature (DOT) invalid>
wrote:
Hi There David,

OK, I think this is the best advice.

A month or two ago I did an update to our system from 2007 to 2010,
and thought x64 is new, shiny and I assumed It was of production
release ready. However, it is not rubust, I have been getting the
errors "object not found", and even "out of memory" and "reserved
error". I kept thinking I'll get to the bottom of it all. More and
more compacting and repairing, as each time, the front end would
become corrupted. The Out-Of-Memory errors appeared to be corrupted
memory space (Virtual Machine with 2Gb allocated). Many of the code
references required the PtrSafe + PrtLong attributes, and while the
code was operating correctly - these strange debugging errors and
corruptions would often occur during design mode, compiling and
saving. Not where you'd expect, ie running the app,

The reason I didn't reply earlier is I took your good advice - and
rolled-back to Office 2010 x32, which has now been working solidly.
The "OPEN" statement which is a simple command works now. (It did
work in x64, before something just went wrong with the interpreter).

It's a bit of a trap for us less informed beings. Obviously we love
x64 Windows, as 8Gb or 16Gb memory, and VMs work well, We have x64
OBDC drivers. MS-Access, x64 was a no brainer. But when you have
DLL references in code, and Declares for 32 Bit code, My limited
experience is now to steer clear of Access x64 for the time being.

I hope others read this thread, and research whether (in 2010) they
should choose carefully when considering Access x64..


Elias Farah.

Am 26.07.2010 19:30, schrieb David W. Fenton:
Hi David,

i have same problems anyhow 32bit or 64bit with win7 ...

we tried to install and work with the files on another partion (e.g.
"D:\")from the pc and seemed to work...

with win7 you are not anymore the "godfather" of your own files and own
harddisk...

( this is why we move back to XP at the moment ) ...

Elias, try to change the folder from C:\ on D:\ or use for testing a USB
Stick and put your file "c:\products.txt" to that device... does it work ?

bye,
MArio

elias <elias.farah (AT) scw (DOT) com.au> wrote in
news:9b5eaac5-92cd-4c34-b4a8-9f887533626f (AT) z30g2000prg (DOT) googlegroups.co
m:

I don't think it's much of a danger, as you have to work extra hard
to install the 64-bit version of Office -- the installer defaults to
32-bit.

I would have thought that if you chose 64-bit the installer would
have advised you on potential issues, but I guess not.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

Mario Schulz <info (AT) removethiswegenspamconcept-dv (DOT) de> wrote in
news:i2rkqa$cc2$1 (AT) online (DOT) de:

What are the permissions on the root of D: ?

This is a terrible mistake. If you were storing files in areas of
your hard drives that have read-only permissions for users in Win7,
you were breaking the rules that have been in place for Windows
permissions since February 2000, when Windows 2000 was released.
That's 10 years of running with incorrect permissions, but it's
because you were running as admin instead of with LUA (i.e., as a
user).

Vista and Win7 now force an issue that many people have avoided for
a decade because they have been running their systems in the worst
possible configuration.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/