Access 97 Will Not Close

[WasAGuru]

I know about KB articles Q164455 and Q190074 - I am using
an If..Then statement that checks the return value of a
function. There are no subforms. All DAO datasets are
guaranteed closed and all variables used are double-
checked to SET to nothing. I changed the If..Then
statement to EXPLICITLY test for true (The failure occurs
if the conditional test happens to be FALSE - if it's TRUE
then after stuff happens and I click the close button, the
database closes nicely). But I still get this darned
error - Access will close the database windows but the
application minimizes into the task bar without closing.
No error messages. No way to close Access without using
Task Manager. Anyone know how to FORCE Access to close -
ALL THE WAY?

Here's the section of code where the problem lies (I see
nothing wrong with any logic here):

Private Sub Form_Load()
Dim rst As Recordset, boolEmp As Boolean
Dim dbs As Database, strSQL As String

On Error Resume Next
Calendar.Value = DateSerial(Year(Now()), Month(Now()),
Day(Now()))
dtmDate.DefaultValue = Empty

' Return reference to current database.
Set dbs = CurrentDb
strSQL = "SELECT * FROM qryEmployees WHERE [strUserID]
= '" & CurrentUser & "';"
Set rst = dbs.OpenRecordset(strSQL)

boolEmp = CurrentUserInGroup("Manager")
If boolEmp = True Then
tbxEmployee.Visible = False
cbxEmployee.Visible = True
Else
cbxEmployee.Visible = False
tbxEmployee = rst.Fields(0)
tbxName = rst.Fields(1)
tbxDepartment = rst.Fields(2)
tbxEmployee.Visible = True
End If
rst.Close
Set rst = Nothing
Set dbs = Nothing
Debug.Print "Form 'frmTimeTracker' Opened Successfully"
End Sub


--PullingMyHairOut(WhatsLeftUpThere)

 

[Douglas J. Steele]

Strikes me that what's in your Form_Unload and/or Form_Close event, as well
as the close button's Click event, is probably more relevant than what's in
your Form_Load event.

 

[Dirk Goldgar]

I know about KB articles Q164455 and Q190074 - I am using
an If..Then statement that checks the return value of a
function. There are no subforms. All DAO datasets are
guaranteed closed and all variables used are double-
checked to SET to nothing. I changed the If..Then
statement to EXPLICITLY test for true (The failure occurs
if the conditional test happens to be FALSE - if it's TRUE
then after stuff happens and I click the close button, the
database closes nicely). But I still get this darned
error - Access will close the database windows but the
application minimizes into the task bar without closing.
No error messages. No way to close Access without using
Task Manager. Anyone know how to FORCE Access to close -
ALL THE WAY?

Here's the section of code where the problem lies (I see
nothing wrong with any logic here):

Private Sub Form_Load()
Dim rst As Recordset, boolEmp As Boolean
Dim dbs As Database, strSQL As String

On Error Resume Next
Calendar.Value = DateSerial(Year(Now()), Month(Now()),
Day(Now()))
dtmDate.DefaultValue = Empty

' Return reference to current database.
Set dbs = CurrentDb
strSQL = "SELECT * FROM qryEmployees WHERE [strUserID]
= '" & CurrentUser & "';"
Set rst = dbs.OpenRecordset(strSQL)

boolEmp = CurrentUserInGroup("Manager")
If boolEmp = True Then
tbxEmployee.Visible = False
cbxEmployee.Visible = True
Else
cbxEmployee.Visible = False
tbxEmployee = rst.Fields(0)
tbxName = rst.Fields(1)
tbxDepartment = rst.Fields(2)
tbxEmployee.Visible = True
End If
rst.Close
Set rst = Nothing
Set dbs = Nothing
Debug.Print "Form 'frmTimeTracker' Opened Successfully"
End Sub


--PullingMyHairOut(WhatsLeftUpThere)

So then, if you comment out this code (before opening the form in Form
View), then open the form in Form View, does the problem disappear? If
so, you might try restoring the code, then commenting out several lines
at a time until you find the block of code that causes the problem.
Then uncomment one line at a time from that section until you find the
line that causes the problem. Here are some lines that raise my
eyebrows:

Calendar.Value = DateSerial(Year(Now()), Month(Now()),
Day(Now()))

Possibly you have an ActiveX calendar control on your form. I don't
know much about these controls, but it seems reasonable that there could
be a problem in the control or the way you're assigning to it.

dtmDate.DefaultValue = Empty

This seems a bit odd. As the DefaultValue property is a string,
wouldn't it make sense to write

dtmDate.DefaultValue = ""

or


dtmDate.DefaultValue = vbNullString

?

boolEmp = CurrentUserInGroup("Manager")

Conceivably there could be an error in the function CurrentUserInGroup()
that is causing the problem

tbxEmployee = rst.Fields(0)
tbxName = rst.Fields(1)
tbxDepartment = rst.Fields(2)

Just conceivably, you may need to explicitly reference the Value
property in these lines:

tbxEmployee = rst.Fields(0).Value
tbxName = rst.Fields(1).Value
tbxDepartment = rst.Fields(2).Value

Those are the only things that, so far, make me take a second look at
them. But try narrowing down the code to identify the offending line,
and then we'll look closer.

 

[Feel_Like_A_Fool]

Problem solved!

It did turn out to be the ActiveX Calendar control causing
the problem and my obfuscated method of feeding it data.
Your response with my comments in BOLD are below:

-- snip --

Here are some lines that raise my eyebrows:

Possibly you have an ActiveX calendar control on your
form. I don't know much about these controls, but it
seems reasonable that there could be a problem in the
control or the way you're assigning to it.

YUP - I FOUND BY COMMENTING OUT THIS LINE, THE PROBLEM
MAGICALLY WENT AWAY. AND I THOUGHT IT WAS SOMETHING LATER
DOWN IN THE CODE SINCE THIS LINE EXECUTED FINE FOR
DIFFERENT USER CLASSES AS DETERMINED BY THE BOOLEAN VALUE
(SEE BELOW).

This seems a bit odd. As the DefaultValue property is a
string, wouldn't it make sense to write
dtmDate.DefaultValue = ""
or
dtmDate.DefaultValue = vbNullString
?

OK... YOU GOT ME ON THAT ONE - FAULT BEING DUE TO
SCRIPTING ON WAY TO MANY PLATFORMS AND LANGUAGES LATELY...
(I KNOW... EXCUSES, EXCUSES...)

Conceivably there could be an error in the function
CurrentUserInGroup() that is causing the problem

NAH... THIS WORKS FINE. IT'S USED NUMEROUS TIMES
THROUGHOUT THE ENTIRE APPLICATION.

Just conceivably, you may need to explicitly reference
the Value property in these lines:

tbxEmployee = rst.Fields(0).Value
tbxName = rst.Fields(1).Value
tbxDepartment = rst.Fields(2).Value

WORKS EITHER WAY IN ACCESS97. NOT THE ISSUE. THIS IS THE
FIRST CHANGE I MADE SINCE I ASSUMED SOMETHING WAS OCCURING
WITHIN THE CONDITIONAL STATEMENT. THIS ASSUMPTION WAS DUE
TO OTHER CLASS USERS BEING ABLE TO CLOSE ACCESS WITHOUT A
HITCH. THIS CONDITIONAL DETERMINES IF USER IS MEMBER
OF 'Manager' GROUP - WHICH WHEN FALSE MEANS CURRENT USER
IS A MERE 'User'. THE FAULT I WAS HAVING OCCURRED ONLY
DURING TESTING A 'User'. I CHANGED THE CODE IN MY
APPLICATION AS PER YOUR SUGGESTION (ASSUMING I WAS
CONFUSING DOTNET DIFFERENCES WITH THIS OLD VBA SCRIPTING
STUFF (IT'S BEEN YEARS SINCE I'VE BEEN TASKED TO LOOK AT
SOMETHING THIS OLD...) - BUT THE FAULT PERSISTED. THIS
PROMPTED ME TO FOLLOW YOUR SUGGESTION OF COMMENTING OUT
THE ENTIRE SUB AND ENABLING IT LINE BY LINE. I FIRST
COMMENTED OUT THE ENTIRE 'FORM_LOAD' PROCEDURE - WORKS
FINE. I NEXT ENABLED ALL LINES WITHIN THE CONDITIONAL
SECTION - SURPRISE! IT WORKED FINE!!! REGARDLES OF USER
CLASS. EXPERIMENTING WITH THE CALENDAR CONTROL LED TO THE
SOLUTION.

THANKS DIRK FOR LEADING ME IN THE RIGHT DIRECTION!!!

MY CLIENT IS HAPPY AND I AM HAPPY. LIFE IS GOOD.

 

[Dirk Goldgar]

"Feel_Like_A_Fool@Ocean_Floor.net"

Problem solved! [...]
MY CLIENT IS HAPPY AND I AM HAPPY. LIFE IS GOOD.

And I am happy. Life is good all around. ;-)