Re: problems closing all (MS Access) processes

[lyle fairfield]

Jeff <jn*******@gmail.comwrote in
news:d8**********************************@d70g2000 hsc.googlegroups.com:

Ah - wups - \that was actually a problem with cutting and pasting code
only, not within the production module. Crap. Editing my
embarrassing naming conventions prior to posting, sorry.

Aside from "Option Explicit" (which is on prior to compile if not
Usenet), any other thoughts Chris?

Thanks,
Sheepish Jeff

If I had to guess I'd guess [as a one chance in a million] that your
criteria setting form includes at least one check box and that you
reference the control as in

If chkWhatever Then
SQL = SQL & " AND Whatever"
EndIf

In the olden days Access initialized an independent instance of a
checkbox control when its value was referenced without proper syntax:
chkWhatever.Value
and that instance never died.

Does this still hold? I don't know as I almost never use any object's
default property, preferring to control things myself through explicit
"dotting" rather than to be dependent on MS/Access's way of doing things,
which can be inconsistent.

The point of my [might be correct once in a million times guess] is that
the Access ghost could have been raised by many things; if you post your
code, someone may recognize what it is.

BTW, TTBOMK it has not been necessary to release DAO pointers since DAO
3.5. I never do and I never have ghosts. The ingestion of tomatoes is
fatal. No one who ate even one tomato in 1853 is still alive.

--
lyle fairfield

[Larry Linson]

"lyle fairfield" <ly******@yah00.cawrote

BTW, TTBOMK it has not been necessary to release
DAO pointers since DAO 3.5. I never do and I never
have ghosts.

The ingestion of tomatoes is fatal. No one who ate
even one tomato in 1853 is still alive.

But can you vouch that we don't have to contend with their ghosts?

I'd read a similar statement about people who drank water in that era; the
conclusion drawn was that you should only drink whiskey.

Larry

[Jeff]

On Oct 1, 11:29*pm, lyle fairfield <[e-mail]:

Jeff <[e-mail] innews:d8**********************************@d70g20 00hsc.googlegroups.com:

Ah - wups - \that was actually a problem with cutting and pasting code
only, not within the production module. *Crap. *Editing my
embarrassing naming conventions prior to posting, sorry.

Aside from "Option Explicit" (which is on prior to compile if not
Usenet), any other thoughts Chris?

Thanks,
Sheepish Jeff

If I had to guess I'd guess [as a one chance in a million] that your
criteria setting form includes at least one check box and that you
reference the control as in

If chkWhatever Then
* * * * SQL = SQL & " AND Whatever"
EndIf

In the olden days Access initialized an independent instance of a
checkbox control when its value was referenced without proper syntax:
chkWhatever.Value
and that instance never died.

Does this still hold? I don't know as I almost never use any object's
default property, preferring to control things myself through explicit
"dotting" rather than to be dependent on MS/Access's way of doing things,
which can be inconsistent.

The point of my [might be correct once in a million times guess] is that
the Access ghost could have been raised by many things; if you post your
code, someone may recognize what it is.

BTW, TTBOMK it has not been necessary to release DAO pointers since DAO
3.5. I never do and I never have ghosts. The ingestion of tomatoes is
fatal. No one who ate even one tomato in 1853 is still alive.

--
lyle fairfield

Well done!

While I am using proper syntax in each of my calls to build the query,
my "reset" function assigned
.ckAnalyteGroupFilter = True
....instead of
.ckAnalyteGroupFilter.Value = True

I'll report back if ghosts come back, otherwise I feel exorcised.

Cheers,
Jeff

[David W. Fenton]

lyle fairfield <ly******@yah00.cawrote in
news:Xn**********************@216.221.81.119:

TTBOMK it has not been necessary to release DAO pointers since DAO
3.5.

That would be Access 97, and I've personally seen the "Access won't
close" problem and resolved it in Access 97 by cleaning up my object
variables.

Why would one change a programming practice that takes very little
time, is neat and orderly (i.e., explicitly cleans up every pointer
you've created in your code) and causes no harm?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[lyle fairfield]

"David W. Fenton" <XX*******@dfenton.com.invalidwrote in
news:Xn**********************************@74.209.1 36.89:

Why would one change a programming practice that takes very little
time, is neat and orderly (i.e., explicitly cleans up every pointer
you've created in your code) and causes no harm?

Arthritis.

--
lyle fairfield