msaccess.exe remains in task manager; which vars cause?

[kiln]

I have a complex Access 2002 app that uses classes, with events, etc.
After this app is run, msaccess.exe remains in memory. I know, or think,
it's because some object var is still hanging around. I've not been able
to isolate it though. Does anyone know of a way to either step on all
object vars as the app is closing (say the main form is closed) or even
better lists all variables that remain. The Locals windows doesn't show
anything staying instantiated, I've really tried a lot of things to get
a handle on this but to no avail.

 

[TC]

One cause of that problem is code of the following kind:

if chkMyCheckbox then ...

instead of:

if chkMyCheckBox.Value then ...

or:

if chkMyCheckBox = True then ...

Maybe a global wildcard search for: *if*chk*then* might find some of
those.

HTH,
TC

 

[TC]

I have a complex Access 2002 app that uses classes, with events, etc.
After this app is run, msaccess.exe remains in memory. I know, or think,
it's because some object var is still hanging around. I've not been able
to isolate it though. Does anyone know of a way to either step on all
object vars as the app is closing (say the main form is closed) or even
better lists all variables that remain. The Locals windows doesn't show
anything staying instantiated, I've really tried a lot of things to get
a handle on this but to no avail.

 

[kiln]

Hi, thanks for responding...but no it's not that checkbox eval bug. At
least as far as I can determine.

 

[kiln]

Oh no...get ready to add another bug to your list. This was caused by a
conditional formatting in a continous subform. "If value = -1, format
backcolor like so, else leave as default" via the GUI interface, not
code. Simplest cond format eval you could ask for.

Too bad Access is decaying into a bug ridden pile of garbage. I know
that now Access is a lowest tier cash cow product to Microsoft, but it
used to be such a great production tool for the right kind of app. Now
everytime the "programmers" on the Access team make a change it creates
a new liability. Autonumbers, OWC functionality, ActiveX controls,
conditional formatting, listbox index errors, this, that, dozens,
hundreds of workarounds or broken features...what a shame.

 

[Dirk Goldgar]

Oh no...get ready to add another bug to your list. This was caused by
a conditional formatting in a continous subform. "If value = -1,
format backcolor like so, else leave as default" via the GUI
interface, not
code. Simplest cond format eval you could ask for.

Hey, kiln, could you provide a simple set of steps to reproduce this
problem, ideally using the Nortthwind sample database? Maybe we can get
it on the "fix" list.

 

[kiln]

Hey, kiln, could you provide a simple set of steps to reproduce this
problem, ideally using the Nortthwind sample database? Maybe we can get
it on the "fix" list.

I'll try to pull the defective parts out into a small db. The field that
produced the memory leak or whatever it is was orig using a function as
a control source. So I thought the function was the problem. But even if
I set the control source to =0, the same msaccess.exe issue persisted.
Take away the single simple con formatting and no memory problem.

But I have a workaround in place where the orig field is calling the
function as it was originally; but it's invisible. Another field,
overlying it, has it's conditional formatting expression evaluating the
result of the orig feild's computation, and it's backcolor changes
instead of the orig field; same visual effect resulting in the UI. No
persistant msaccess.exe results. That just can't make any sense but it
is behaving like that.

I'll attempt to strip out the zillion form objects around this and see
it's it's still acting up, and I could send that. BTW I did decompile
and import to new db very early on in the process, to no avail.

 

[Dirk Goldgar]

I'll try to pull the defective parts out into a small db. The field
that produced the memory leak or whatever it is was orig using a
function as
a control source. So I thought the function was the problem. But even
if I set the control source to =0, the same msaccess.exe issue
persisted. Take away the single simple con formatting and no memory
problem.

Hmm, that is odd. And suspiciously like a bug.

But I have a workaround in place where the orig field is calling the
function as it was originally; but it's invisible. Another field,
overlying it, has it's conditional formatting expression evaluating
the result of the orig feild's computation, and it's backcolor changes
instead of the orig field; same visual effect resulting in the UI. No
persistant msaccess.exe results. That just can't make any sense but it
is behaving like that.

I'll attempt to strip out the zillion form objects around this and see
it's it's still acting up, and I could send that. BTW I did decompile
and import to new db very early on in the process, to no avail.

I haven't heard about this particular bug before, but that doesn't mean
anything. If you can come up with a minimal scenario to reproduce it,
either in a small example database or as a list steps to follow in a
blank database or Northwind, send it along to me at the address you get
by removing NO SPAM from the reply-address of this message. Nothing
bigger than 1MB, please.

 

[kiln]

I'm rather incredulous, but the bug persists after chopping out all db
objects but two tables one query and one form. I'll zip and sent to you.

 

[Dirk Goldgar]

I'm rather incredulous, but the bug persists after chopping out all db
objects but two tables one query and one form. I'll zip and sent to
you.

I received your message, and will look at it as soon as I get the
chance.

 

[Michael Wong]

Hi Klin,

I also came into this problem, just yesterday.
I would have searched long before I find the problem. It was a bug in my
code by one in Access (2002)! Luckily, I found your posted, it saved me
quite a lot of debugging time.
What I had is a simple condition: If field value is less than: 0
Of course, Access wouldn't quit from the memory...
What I did now is have: If expression is: IsNegative([myField])
And it worked fine since then. Just needed to create the simplest
function...

I'm wondering if someone came to a better solution?

Thanks

 

[kiln]

Your workaround sounds fine, I have one for a slightly different
implementation. Only Microsoft can provide a real fix.

Hi Klin,

I also came into this problem, just yesterday.
I would have searched long before I find the problem. It was a bug in my
code by one in Access (2002)! Luckily, I found your posted, it saved me
quite a lot of debugging time.
What I had is a simple condition: If field value is less than: 0
Of course, Access wouldn't quit from the memory...
What I did now is have: If expression is: IsNegative([myField])
And it worked fine since then. Just needed to create the simplest
function...

I'm wondering if someone came to a better solution?

Thanks

I'll try to pull the defective parts out into a small db. The field that
produced the memory leak or whatever it is was orig using a function as
a control source. So I thought the function was the problem. But even if
I set the control source to =0, the same msaccess.exe issue persisted.
Take away the single simple con formatting and no memory problem.

But I have a workaround in place where the orig field is calling the
function as it was originally; but it's invisible. Another field,
overlying it, has it's conditional formatting expression evaluating the
result of the orig feild's computation, and it's backcolor changes
instead of the orig field; same visual effect resulting in the UI. No
persistant msaccess.exe results. That just can't make any sense but it
is behaving like that.

I'll attempt to strip out the zillion form objects around this and see
it's it's still acting up, and I could send that. BTW I did decompile

 

[Michael Wong]

It's funny in this case it bugged. I just found I had an earlier Access
program which also has conditional formatting which is even simpler: If
field value is equal to 0... And it works...
Anyway, will continue with the workaround for the time being.

Your workaround sounds fine, I have one for a slightly different
implementation. Only Microsoft can provide a real fix.

Hi Klin,

I also came into this problem, just yesterday.
I would have searched long before I find the problem. It was a bug in my
code by one in Access (2002)! Luckily, I found your posted, it saved me
quite a lot of debugging time.
What I had is a simple condition: If field value is less than: 0
Of course, Access wouldn't quit from the memory...
What I did now is have: If expression is: IsNegative([myField])
And it worked fine since then. Just needed to create the simplest
function...

I'm wondering if someone came to a better solution?

Thanks

Oh no...get ready to add another bug to your list. This was caused by
a conditional formatting in a continous subform. "If value = -1,
format backcolor like so, else leave as default" via the GUI
interface, not
code. Simplest cond format eval you could ask for.

Hey, kiln, could you provide a simple set of steps to reproduce this
problem, ideally using the Nortthwind sample database? Maybe we can get
it on the "fix" list.


I'll try to pull the defective parts out into a small db. The field that
produced the memory leak or whatever it is was orig using a function as
a control source. So I thought the function was the problem. But even if
I set the control source to =0, the same msaccess.exe issue persisted.
Take away the single simple con formatting and no memory problem.

But I have a workaround in place where the orig field is calling the
function as it was originally; but it's invisible. Another field,
overlying it, has it's conditional formatting expression evaluating the
result of the orig feild's computation, and it's backcolor changes
instead of the orig field; same visual effect resulting in the UI. No
persistant msaccess.exe results. That just can't make any sense but it
is behaving like that.

I'll attempt to strip out the zillion form objects around this and see
it's it's still acting up, and I could send that. BTW I did decompile

 

[Dirk Goldgar]

It's funny in this case it bugged. I just found I had an earlier
Access program which also has conditional formatting which is even
simpler: If field value is equal to 0... And it works...
Anyway, will continue with the workaround for the time being.

This bug is supposed to be fixed by Office XP Service Pack 3. I haven't
yet installed that SP myself, so I can't confirm it, but I'd recommend
trying it.

 

[Michael Wong]

Yes, I think I should install SP3, or maybe upgrade to Office 2003?

 

[Dirk Goldgar]

Yes, I think I should install SP3, or maybe upgrade to Office 2003?

I don't know for sure that the bug is fixed in Office 2003, so if I were
you I'd either look for confirmation first, or just install SP3 for
Office XP.