Access 2007 and win 7, error on computed controls

[Alain Bourgeois]

Hi,

I have a form with a "computed" edit, meaning with ControlSource value:
=DCount("[Scéance prestée]";"ReqCountSéanceD").

Using windows 7 I have to press the F9 key to fore the value to be
displayed, otherwise ni value is displayed.
Using windows xp and vista, no problem. Using older versions of access
(2000,2002,2003) with win 7, as far as I know, also no problem.

This problem occured also with access 2007 on windows vista and has been
corrected by a windows vista service pack.
Surprising that access has not been tested under win 7, I wonder if these
tools are written by the same company.

I suppose I can't do anything else than waiting for a patch?
I also suppose it is not feasable to get an access 2003 instead of access
2007?

Regards;
Alain Bourgeois

 

[David W. Fenton]

I have a form with a "computed" edit, meaning with ControlSource
value:
=DCount("[Sc‚ance prest‚e]";"ReqCountS‚anceD").

Using windows 7 I have to press the F9 key to fore the value to be
displayed, otherwise ni value is displayed.
Using windows xp and vista, no problem. Using older versions of
access (2000,2002,2003) with win 7, as far as I know, also no
problem.

This problem occured also with access 2007 on windows vista and
has been corrected by a windows vista service pack.
Surprising that access has not been tested under win 7, I wonder
if these tools are written by the same company.

I suppose I can't do anything else than waiting for a patch?
I also suppose it is not feasable to get an access 2003 instead of
access 2007?

Possible workarounds:

1. assign the value of the control explicitly in code, based on the
update events of relevant controls or the form (and the OnCurrent
event).

2. write a function to replace DCount() and use that instead.

I am sure the first will work, though getting the events right might
be tricky. The second will only work if the problem is inside
DCount() rather than in the updating of calculated controls in
Access forms.

 

[Alain Bourgeois]

1. Solution 2 doesn't work. It is a pure display problem, not a computation
problem. Pressing F9 shows the right value.
2. Problem: this application has 250 forms (with some computed controls on
each + also lots of reports), and at computers of > 100 customers (access
2000->2007 and win xp / vista / 7).
I don't want to change the whole application just because of an
incompatibility bug in win 7 or access 2010.
This works with win xp! And this is also supposed to work according to
MS-Access documentation.

I have a form with a "computed" edit, meaning with ControlSource
value:
=DCount("[Sc,ance prest,e]";"ReqCountS,anceD").

Using windows 7 I have to press the F9 key to fore the value to be
displayed, otherwise ni value is displayed.
Using windows xp and vista, no problem. Using older versions of
access (2000,2002,2003) with win 7, as far as I know, also no
problem.

This problem occured also with access 2007 on windows vista and
has been corrected by a windows vista service pack.
Surprising that access has not been tested under win 7, I wonder
if these tools are written by the same company.

I suppose I can't do anything else than waiting for a patch?
I also suppose it is not feasable to get an access 2003 instead of
access 2007?

Possible workarounds:

1. assign the value of the control explicitly in code, based on the
update events of relevant controls or the form (and the OnCurrent
event).

2. write a function to replace DCount() and use that instead.

I am sure the first will work, though getting the events right might
be tricky. The second will only work if the problem is inside
DCount() rather than in the updating of calculated controls in
Access forms.

 

[David W. Fenton]

2. Problem: this application has 250 forms (with some computed
controls on each + also lots of reports), and at computers of >
100 customers (access 2000->2007 and win xp / vista / 7).
I don't want to change the whole application just because of an
incompatibility bug in win 7 or access 2010.
This works with win xp! And this is also supposed to work
according to MS-Access documentation.

I have a hard time conceiving of a valid scenario where you really
do need all those DCounts(). There's got to be a better, more
efficient way to retrieve and display the necessary data, but given
that we don't know what you are doing, it's hard to suggest an
alternative.

The fact that it works in an 8-year-old version of Windows and a
3-year-old version of Access isn't going to be of much comfort 2
years from now when none of your users are running WinXP or anything
but A2010. So, you really need to redesign the front end to avoid
the bug.

Honestly, I think it's just the canary in the coal mine. That is,
you have a suboptimal design in the first place, and this bug in the
Win7/A2010 platform (and I would agree it's likely a bug) just
flushed out a bad design.

But I'm speculating without really knowing the details.

 

[Alain Bourgeois]

1. It not only dcount, it is ALL controls having a function call in
ControlSource (DCount, DLookup, even your own functions).
2. Where is it written (which line in the user manual) that this is not
supported anymore in access 2010 or windows 7 (Access 2010 and win xp work
fine)????
MS office and Windows are NOT a free tool (such as eclipse, java, ...).
So they have to work, to be supported, and bugs have to be corrected.
3. "The fact that it works in an 8-year-old version of Windows and a
3-year-old version of Access isn't going to be of much comfort"
The fact is that old versions work and newer ones not! I would have
expected older versions not to work on win 7, but it is not the case!
The fact is that these new versions just have more bugs, that occur when
using new versions together. And even it there are good things in new
versions, if these are bugged, these are unusable in a production
environment.
4. I chosed MS as development tool bcs I though OS and tool would be
integrated correctly, and these tools are really great (I mean: the ones
without bugs). Perhaps I'm wrong and I should go to Mac or windev, where
these problems don't occur (although I'm sure other problems also happen)...
but I prefer hoping these bugs will be soon corrected by MicroSoft.

..

 

[David W. Fenton]

1. It not only dcount, it is ALL controls having a function call
in ControlSource (DCount, DLookup, even your own functions).

I don't have any applications that have such controlsources after 14
years of professional Access development. Maybe you don't need them,
either?

Sure, it *should* work, but it obviously doesn't in the environment
your users have to use, so maybe it's time to find a better way.

2. Where is it written (which line in the user manual) that this
is not supported anymore in access 2010 or windows 7 (Access 2010
and win xp work fine)????
MS office and Windows are NOT a free tool (such as eclipse,
java, ...).
So they have to work, to be supported, and bugs have to be
corrected.

Dunno what your point is here. Whether it's a bug or by design, the
fact is, it doesn't work, and I can't imagine a scenario where it's
a good design in the first place. You may have gotten away with this
design for a long time, but now it's biting back, and perhaps it's
time to re-engineer it to work differently. Then you won't need to
wait for the "bug" to be fixed. Your app will likely be FASTER, as
well.

3. "The fact that it works in an 8-year-old version of Windows and
a 3-year-old version of Access isn't going to be of much comfort"
The fact is that old versions work and newer ones not! I would
have
expected older versions not to work on win 7, but it is not the
case!
The fact is that these new versions just have more bugs, that
occur when
using new versions together. And even it there are good things in
new versions, if these are bugged, these are unusable in a
production environment.

Be that as it may, the new versions are here to stay, and you either
prohibit your users from using them until the "bug" is fixed (if it
ever is), or you re-engineer your application to avoid the problem
entirely.

4. I chosed MS as development tool bcs I though OS and tool would
be integrated correctly, and these tools are really great (I mean:
the ones without bugs). Perhaps I'm wrong and I should go to Mac
or windev, where these problems don't occur (although I'm sure
other problems also happen)... but I prefer hoping these bugs will
be soon corrected by MicroSoft.

You did not address at any point my main assertion, that your design
is WRONG. Using multiple domain aggregate functions is just
something that raises a red flag for me (particularly if any of them
are looking up data from the same table). It sounds like an
erroneous design from the get-go, and if you redesigned to not use
all the domain aggregate functions, the "bug" would be irrelevant.

But you didn't even touch that assertion at all, and instead railed
against MS.

I'm a big fan of righteous indignation myself, as it's quite
self-satisfying. But it alone can't solve your problem. I'm
suggesting looking at something that could fix the problem, but I
don't have enough information to offer any specific solutions. I'm
interested in the problem because I'd like to see if my initial
reaction that lots of domain aggregate calls are a design error is
true or not.

So post some details of what you're trying to do and what data
you're trying to display, and then I'll try to help you develop an
alternate solution.

That is, if you're interested in fixing the problem more than you're
just venting.