win 7 + access 2007 runtime => errors

[Alain Bourgeois]

Hi,

I have a continuous form with one field with the following characteristic:
* controlsource property is a vb function call (e.g.:=getresttext([ID
Traitement];[DateRDZ])
* There is a conditional formating on this field, based on an expression
(true/false)

This works with any access>= access 2k and any windows >=win '98 (if service
packs are installed) but win 7 has a trouble with access 2007 runtime (can't
we buy access 2003 anymore? ).
(I didn't test but wouldn't be surprised if same would occur with full
version of access 2007).

But with windows 7 (starter edition, home edition, professional edition),
the field is shown as blank (value is not shown), and value appears when one
of the following events occur:
* move the mouse over the zone, value appears for the zone (so it is a
real display issue, even not a computation issue),
* Or click in the zone, value appears for the zone,
* Or press F9, value appear for all records on the screen.

Access runtime 2007 on win xp doesn't have any problem with this.

We had this problem in the past with vista, problem was corrected by
installing vista service pack 1.
I applied all win7 patches, nothing is solved.
We now have the same problem with windows 7... new version, same bugs, it
seems MicroSoft Office is not in the list of the applications tested when a
new windows version is sold (Incredible!)

Does anyone has a solution for this?
I hope a win 7 patch should solve this, but when?

Regards,
Alain

 

[Access Developer]

Alain, you can look at sites where old software is sold for Office 2003
(I've bought and sold used and new non-current versions of software on eBay
and seems there's another site specializing in old software -- you should be
able to seek it out by Googling).

If there are computer "swap meets" around your area, you may also be able to
obtain older versions, sometimes new in shrinkwrap, there. I went to a swap
meet in the Dallas, TX area while Office 2000 was current, and found one
vendor who had still new in shrinkwrap copies of Access 1.0 and Access 2.0
for sale. But, even more pertinent, another dealer had inexpensive copies
of Office 97 -- several of my user group colleagues bought those Office 97
Pro copies, which as far as any of us knows, are genuine. At least one or
two of them used those copies to qualify for installing upgrades to later
versions.

Larry Linson
Microsoft Office Access MVP

 

[Alain Bourgeois]

I know I can find "second-hand" legal office versions.
But it would be better for microsoft to correct these bugs.
It is very strange that problem occur only with the most up-to-date versions
of microsoft software (office 2007 or 2010 on win 7) and not with previous
ones.

If microsoft doesn't correct a such obvious bugs, it really means telling to
his customers : "go to other software, we don't want to sell office
anymore".
MS-Office is a great tool and is not free, the programming environment
(database, vba, macros, ...) is the difference with open office suite, and
people agree to pay to get this difference... But if this feature doesn't
work correctly anymore, then buying microsoft office doesn't have any
interest anymore.

If I look at last versions of windows (vista, 7), it seems that everything
is done to make life difficult to microsoft office programmers!
Some samples?
* User account control: if not turned off, a drag & drop of a file is not
possible from an application to another (e.g. from scansoft paperport to
access hyperlink field on a form),
* sandbox mode has to be set to 0 in registry, otherwise a macro cannot call
a vba function,
* opening office 2000 ressets office 2007's sandbox mode to 3 (why why
why?),
* directories where applications are stored have to be approved,
* registry key have to be added to avoid a security warning if a user clicks
a control with a hyperlink property on an access form (occured in access
2003 also),
* fields with conditional format don't work with win 7 (and also don't work
on vista if sp1 is not installed),
* if computer is win 7-64 bits, mdb has to be compiled with access 2007 to
be usable by access 2007 runtime (and this is not the case with win 7 32
bits),
* ...

Last but not least, none of these features (implemented "for security
reasons") will prevent a computer from getting infected by a virus.
The added value of these things is, according to my experience, 0, null,
nada... except boring end-users and developers.

Regards,
Alain

 

[Access Developer]

If you were expecting me to mount a defense for Access 2007 or Access 2010
(or any particular version of Windows), I hope I'm not disappointing you.

I acknowledge all these drawbacks and also quote my Access clients who say
that if they move to a later version than Access 2003, they will have
re-training expenses, plus a long time of their employees making actions
"second nature" as they have with Classic Office because of the drastic and
dramatic change to the user interface with the advent of The Ribbon.

As my clients do not have needs for me to help them with Access versions
after 2003, that is the most recent version of Access installed on any of my
computers. That is why I was trying to be helpful by suggesting sources for
obtaining "Classic Access".

Larry Linson
Microsoft Office Access MVP

 

[David-W-Fenton]

If I look at last versions of windows (vista, 7), it seems that
everything is done to make life difficult to microsoft office
programmers! Some samples?
* User account control: if not turned off, a drag & drop of a file
is not possible from an application to another (e.g. from scansoft
paperport to access hyperlink field on a form),

UAC is a really good thing, as it finally makes setting up all users
as administrators a safe thing to do. The problem is that after
Windows was properly locked down, vast numbers of users still
continued running as admin instead of running as a user-level
account. Because of that, many software makers never really adapted
(Intuit, I'm looking at you!), and thus when UAC came along, they
were caught with their pants down, with software that broke.

* sandbox mode has to be set to 0 in registry, otherwise a macro
cannot call a vba function,

This is not a Win7/Vista issue. It's been that way since at least
A2003.

* opening office 2000 ressets office 2007's sandbox mode to 3 (why
why why?),

This is not a Win7 issue. It's a decision by MS to be autocratic
about allowing only one version of Office to be registered at a
time. It's not an issue for end users, who mostly only have one
version of any Office app installed at a time, but it's terribly
inconvenient for developers.

But it's not a Win7 issue -- it's a result of MS's design of how
Office works, and it's been this way since Office 2000.

* directories where applications are stored have to be approved,

I don't know what this means, but the fact is that since Windows
2000, it has been the case that you shouldn't install an Access app
in the Program Files folder or in the root of the system drive --
both of those locations have been read-only for non-admin users
since Win2000. From that time on, the only proper place for
installing an Access app has been the user profile, and that is BY
DESIGN. Vista/Win7 FORCE this on you because of UAC, and IT'S A GOOD
THING. It's long past time for people to stop running their copies
of Windows in the least secure mode possible.

* registry key have to be added to avoid a security warning if a
user clicks a control with a hyperlink property on an access form
(occured in access 2003 also),

Not a Win7 issue -- that's A2003.

* fields with conditional format don't work with win 7 (and also
don't work on vista if sp1 is not installed),

I don't know about this one. Any Knowledge Base articles on it?

* if computer is win 7-64 bits, mdb has to be compiled with access
2007 to be usable by access 2007 runtime (and this is not the case
with win 7 32 bits),

I have always been wary of compiling to MDE in anything but the
target runtime environment. Indeed, most of my apps are not deployed
as MDEs at all, because I've just encountered too many problems.
It's also a lot easier to debug an MDB, and my apps are riddle with
bugs that need fixing. If I distributed MDEs, it would be much
harder to identify and fix these bugs (for instance, I could never
do an instant fix over the phone by telling the user what to type --
I don't do this often, but occasionally I can get an end user past a
simple bug by doing that).

But of course, if MS says you're supposed to be able to do this, you
should be able to do so.

 

[David-W-Fenton]

Last but not least, none of these features (implemented "for
security reasons") will prevent a computer from getting infected
by a virus. The added value of these things is, according to my
experience, 0, null, nada... except boring end-users and
developers.

There are three types of things in your list:

1. UAC (1 & 4)

2. issues with Office itself (2, 3, 5)

3. bugs (6, 7)

Your #4 (locked down folders) have been there since 1999, but only
Vista/Win7 have forced people to get with the program. If you didn't
adapt in the Win2000 era, then it is really your problem, and I have
no sympathy whatsoever when you are forced to fix your erroneous
practices in order that they work with UAC. Perhaps you should read
this:

http://en.wikipedia.org/wiki/Principle_of_least_privilege

Your #1 is just a complaint about applications that have not been
updated to account for UAC. This is not the fault of Microsoft or of
Windows, but of the makers of the software for not updating to keep
up, or your own fault for not acquiring a version of the software
that is compatible with the OS you're running.

Both of these things are definitely helps for preventing the running
of nefarious code, i.e., viruses, trojans and worms. The main reason
that most exploits now come through email and the browser is
precisely because these changes in the OS security have prevented
most of the old ones from propagating well (because they required
permissions that they no longer are able to elevate to easily).

The Office issues are not new at all. The dueling registrations have
been a problem since Office 2000 (though that was actually solvable
when the fight was with Office 97, since the O97 registration files
were editable in a way that would cause things to remain stable).

I would agree that #2 and #5 are ineffectual, but I don't think they
are so much aimed at stopping viruse, etc. (which don't actually
exist in Access) but in allowing corporate IT shops from preventing
the running of unauthorized code. This is not in the interests of
Access developers at all, of course, and doesn't help end users. But
those two consistuencies don't have MS's ear to the extent that big
corporate IT departments do. But it's also the case that these
issues have been there for well over 5 years, so why you'd be
complaining about them now, I can't say.

The last two on your list are just bugs so far as I can tell, so not
relevant to AV or Win7 at all.

Looks like a real mixed bag to me. Your criticisms don't seem
coherent, nor relevant to the specific topic (A2007 runtime and
Win7), though this may be the first time you've encountered them in
a live project.

 

[Alain Bourgeois]

Concerning UAC:
1. Most users are administrator of their computer (they own it, no?).
2. They work in workgroup and write documents to a shared folder, and
work with a shared database.
-> I can agree that if you give a dummy the right to install viruses they
will be able to do it. Here: users are professionnals that use applications,
even not connected to the internet... so the risk to get a virus is 0.
-> I would agree with you if such "security things" would prevent users to
get spywares/viruses. I can show you lots of computers where these "security
things" didn't solve anything

Concerning office issues: in access<=2003, tools / security / low. Easy to
fix.
However, I can live with these 2 issues. Most important problem is bugs. And
bugs # 6 is related to win 7, as it doesn't occur on other windows versions
with the same access version.

But however, I don't dare to think to all reg keys we will have to add in
access 2015... But perhaps in 2015 I will have brought my office
applications to Apple (seriously thinking about it).

 

[David-W-Fenton]

Concerning UAC:
1. Most users are administrator of their computer (they own
it, no?).

They shouldn't be RUNNING as administrator (unless they have
Vista/Win7, in which case, they can log on as admin and by default,
all processes will run with a user-level security token, unless
you've overridden the default).

They should be running with user-level permissions when they are
working as a user. They should only be running as admin when they
are performing administrative functions.

This is pretty basic. It's the way Linux works (SUDO) and it's the
way Mac OS X works. It's the way Windows always should have worked,
but it was only properly implemented beginning with Windows 2000
(when proper permissions were applied that made system areas
read-only for user-level logons) and finally properly implemented in
Vista (though with UAC defaults set so that it was noisy and
annoying; Win7 fixed that problem so that UAC is now pretty much not
seen unless you're really doing something that requires admin
permission).

Did you read the Wikipedia article I cited? It explains the
principle of running with the least privileges:

http://en.wikipedia.org/wiki/Principle_of_least_privilege

When you run with excess privileges, you risk delegating too much
authority to processes that don't need it, including nefarious ones.

2. They work in workgroup and write documents to a shared
folder, and
work with a shared database.

So, a peer-to-peer network with no domain controller. In that case
you can use the EVERYONE group on the "server" so that shared
documents are available to everyone without user authentication.
This is not my preferred environment, but it's OK. It's also the
default for shares in that environment, so shouldn't be an issue.

-> I can agree that if you give a dummy the right to install
viruses they will be able to do it.

By running as admin, you are doing just that.

Here: users are professionnals that use applications,
even not connected to the internet... so the risk to get a virus
is 0.

No, it's absolutely NOT zero.

And UAC under Win7 is fine. It's not bothersome and it interferes
with almost nothing. If you have software than can't function under
UAC, then you need to get a software update for Vista/Win7, because
it's badly-designed software. Any software designed to run under
Windows 2000 or later with a user-level logon should have NO
problems running under UAC. Any software that DOES have problems
under UAC is actually more than ten years out of date in its design
(e.g., QuickBooks).

-> I would agree with you if such "security things" would prevent
users to get spywares/viruses. I can show you lots of computers
where these "security things" didn't solve anything

They can still get user-level infections, yes, but that's much less
of a risk to the software ecosystem than if they ran as admin.

Concerning office issues: in access<=2003, tools / security / low.
Easy to fix.
However, I can live with these 2 issues. Most important problem is
bugs. And bugs # 6 is related to win 7, as it doesn't occur on
other windows versions with the same access version.

It may be "related" to Win7 (I think it's more a 64-bit issue than a
Win7 issue), but it's not a Win7 bug -- it's something that ought to
be fixed in Access, but it won't because A2003 is old.

But however, I don't dare to think to all reg keys we will have to
add in access 2015... But perhaps in 2015 I will have brought my
office applications to Apple (seriously thinking about it).

If you'd keep up with proper user configurations and not insist on
running under rules that went out the window in 1999, you'd have a
LOT fewer problems.