Error 2455 on close of db

W

WestWingFan

Ok, I'm missing something here. Any help would be appreciated. I have a form
and I'm getting Error 2455 when I close the database from this form.

What I know so far...
1) If the user opens the form (does not change records) and closes the
database (x's out) then there is no error.
2) If the user opens the form and navigates to a different record, then
closes the database, error 2455 occurs.
3) If I click on debug when the error occurs, the database closes anyway.
I'd love to give you the line of code where it fails, but don't know how to
find that at the moment - the code compiles fine.

I have two other similar forms where the "onclose" event is identical and if
I test them against the two scenarios above - neither one gives any error.

Thanks in advance!
 
J

Jack Leach

Can you post the code that's in the close event? Are you doing anything in
any other events (on current perhaps) that you may not be cleaning up (loose
objects, recordsets, etc.)?

--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)
 
W

WestWingFan

Jack,

Thanks for the response. Here's the code for the Close event.

Private Sub Form_Close()
If CurrentProject.AllForms("Entry Form").IsLoaded Then
DoCmd.SelectObject acForm, "Entry Form"
DoCmd.Maximize
End If
End Sub

Also, here's the code for the OnCurrent event. I hope I've cleaned
everything up, but you may see something I don't. Thanks again!

Private Sub TogEdit_AfterUpdate()
'Purpose: Set the Caption of the Edit toggle button.
Dim strCaption As String

With Me.TogEdit
If .Value = -1 Then
strCaption = "Save"
ElseIf .Value = 0 Then
strCaption = "Edit"
End If
If .Caption <> strCaption Then
.Caption = strCaption
End If
End With
End Sub

Private Sub Form_Current()
Call TogEdit_AfterUpdate
End Sub
 
J

Jack Leach

I don't see anything specifically *wrong*, but perhaps you could try getting
away from checking the IsLoaded property (somewhere along the lines I've
heard that this may not be all that wonderful of a thing to use... but I
don't remember where or why).

Maybe you can check the Forms collection instead... if the form is open, it
will be in that collection.

Private Sub Form_Close()
Dim frm As Form
For Each frm In Forms
If frm.Name = "Entry Form" Then
DoCmd.SelectObject acForm, frm.Name
DoCmd.Maximize
End If
Next
Set frm = Nothing
End Sub

I'm not familiar with the SelectObject command... I tend to use SetFocus but
I'm not exatcly sure what the difference is.

Pulling at straws either way... I don't see any reason for the error to
throw, or the db to crash, but I would at least try getting away from
IsLoaded.

hth
--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)
 
W

WestWingFan

Not to quibble, but if it was the IsLoaded property, wouldn't that cause the
same error when I test the other two forms that have the exact same close
event?

Also, the database doesn't crash, it just exits - regardless if you choose
"end" or "debug" when the error occurs.

Thanks for the suggestions - I'll try them out.
 
J

Jack Leach

Not to quibble, but if it was the IsLoaded property, wouldn't that cause the
same error when I test the other two forms that have the exact same close
event?

Possibly. But I've heard better minds than ours denounce this property, so
I'm not ruling out the possibility.

Also, the database doesn't crash, it just exits - regardless if you choose
"end" or "debug" when the error occurs.

Is it supposed to exit? I see no Application.Quit... so I would count that
as a crash, unless there's something I'm not seeing. I'm pretty sure that
Debug should bring you right to the line of the error... regardless if this
close happens to be called by AppQuit or not. How about some error handling
with a break and a Resume... are you using that? If you can't track the
faulty like that way I would definitaly put this in Crash catagory.

Something to think about anyway...

--
Jack Leach
www.tristatemachine.com

"I haven''t failed, I''ve found ten thousand ways that don''t work."
-Thomas Edison (1847-1931)
 
W

WestWingFan

Thanks for hanging in there with me. The error message only appears if you
have this form loaded (a few records in) and then use the close/x box at the
upper right to exit the database. I think you may be on to something with the
oncurrent event or the error handling (it would be handy to see what is
causing the error). What error handling code do you suggest?
 
J

Jack Leach

What error handling code do you suggest?

Here's a skeleton:

'====================
Private Sub Form_Close()
On Error Goto Err_Proc

'put all your normal code here


Exit_Proc:
'cleanup
Exit Sub
Err_Proc:
MsgBox "Error " & Str(Err.Number) _
& " - " & Err.Description
Resume Exit_Proc
Resume
End Sub
'====================


This is a simple-as-possible error handler (the best way to go, IMO). It
will display a message stating the error number and the dscription of the
error. Here's a breakdown on how it works and why you need what's there:


On Error Goto Err_Proc

This should always be the first line after the sub/function declaration. It
tells your procedure that when an error occurs, go to the line label
Err_Proc. Any errors with the exception of something that the Access
developers might have missed will now be directed to your "handler"


Exit_Proc:
Exit Sub

This is your exit point for the sub... if anything goes wrong anywhere in
your code, or you happen to meet a condition and no longer need the rest of
the code to run, always direct your code here by using Goto Exit_Proc. Put
any "cleanup" code here: ex. closing recordsets and setting objects to
Nothing so they aren't hanging around in memory waiting to confuse Access and
screw things up.

Resume Exit_Proc

The Resume statement is used in conjunction with errors... this simply tells
your code to go to the label Exit_Proc (which you will be closing out any
open objects, etc. before it hits the Exit Sub line). With no intervention
from you, this line will always be run on an error... so your procedure can
elegantly exit.

Error_Proc:

This is the *label* that defines your error handler... per the line On Error
Goto Err_Proc, all errors will be handled in the code that follows this label.

The msgbox line should be self-explanitory. But it also has a second very
important use... it stops your code until you click OK, giving you means to
enter your code for debugging (Alt + F11 opens the code window... now drag
the yellow arrow to a line you want to execute and hit F8 to run the line).


Resume

This one is key for debugging... under normal circumstances, this line will
never be executed (the line before it will always redirect to the exit point
of the procedure). A simple Resume statement (as opposed to Resume <label>
or Resume Next) will send the code to the line that caused the error. So
here's the debugging procedure...


- Add the error handler

- Recreate the error

- When the MsgBox pops up with the number and description:

- Hit Alt+F11 to open the vba window

- your MsgBox line in the error handler should be highligted in yellow, with
a little yellow arrow at the left

- Drap/Drop the yellow arrow on the left to the Resume statement

- Hit F8 (to proccess that particular line of code)

- your code should jump back to the line in the procedure that caused the
error, allowing you to pinpoint the source of the error.


Keep in mind that this won't tell us WHAT the problem IS, but simply where
the problem is coming from... but that is always the first step to to
resolving any issue.

Error handling should be included in every sub or function you write. Go to
www.mztools.com to download a complete free addin for the VBE that will add
your customized error handler at the click of a button. This addin is
recommended by hundreds (thousands?) of developers... in fact, one fan states
that he loves MZTools so much he will name his firstborn son MZTools
(hahaha). Seriously though, it's that good... no hidden crap, just an awsome
awsome tool.



So do this and let me know how you make out. If, by some strange chance,
you are still not able to catch the error by this method, don't lose hope...
there's other but far more invloved) ways. I doubt that will be the case
though. If this doesn't work then there is a problem with Access, not your
code. Post back, we'll get this one figured out!

--
Jack Leach
www.tristatemachine.com

"I haven''t failed, I''ve found ten thousand ways that don''t work."
-Thomas Edison (1847-1931)
 
J

Jack Leach

The error message only appears if you
have this form loaded (a few records in) and then use the close/x box at the
upper right to exit the database.


ahhhhh! I thought this was happening when you closed the Form! No wonder
access is closing if you're closing the app itself <duh on my part>

This is starting to make a little more sense now. So aside from my previous
post on error handling (which you still should use), here's something else to
think about.

When the application itself closes, by way of the File -> Close or the X
button (or Alt+F4), all of a sudden there's a *lot* of stuff going on behind
the scenes. Access is now going through its own shutdown procedure (which
has nothing at all to do with any code you may have). There is a specific
order to how Access handles this, but I don't know what it is. Access needs
to unload everything from loaded forms or reports or open tables, clear out
all variables, properties, so on and so forth.

The key here is to keep in mind that Access has no regard for your code
during this process. If it happens to close something that is needed by
something that hasn't been closed or cleared yet, you're going to start
seeing errors such as these. I can't pretend I know what the *exact* issue
is with the order of operations (nor would anyone else, I think), but this is
most assuredly the root of your problem.

Here's the workarounds... both cheap and easy (not recommended) and the
*real* way.

Cheap and Easy:

using the error handling technique from my previous post... capture that
particular error number:

'===============
Private Sub Form_Close()
On Error Resume Goto Err_Proc

'your code

Exit_Proc:
Exit Sub
Error_Proc
If Err.Number = 2455 Then
Err.Clear
Else
MsgBox Str(Err.Number) & Err.Description
End If
Resume Exit_Proc
Resume
Exit Sub
'===============

This will effectively hide the error. Key word *hide*... the error still
occurs, you just won't see it. Therefore... bad practice. Also keep in mind
that at any other time this error may occur in this procedure (under more
normal circumstances), you won't be notified. Therefore... bad practice.




The *real* way:

Remove all native access features from your app and replace them with your
own (menus/ribbons etc). Use the following link to disable the X button and
Close command from the File menu if you do not hide the menu.

http://support.microsoft.com/default.aspx/kb/245746

On the app startup, open a hidden form. This form will stay open for the
duration of the app. In this form's Unload event, use code to elegantly
clean up the application before access quits.

When you use a custom menu or exit button, close this form... the unload
events that you run will need to *elegantly* handle any open objects, before
access attempts to do it on its own. This is the only effective way to gain
complete control over how Access cleans up *your* portion of the project.

A typical Unload event of a hidden form will look like this:

Private Sub Form_Unload(Cancel As Integer)

'check all open objects and close them accordingly

'log out the user if applicable

'write any table or file logs if application

'whatever else you may want to make sure of

Application.Quit
End Sub


This is the only effective way to control a shutdown and avoid the types of
errors you are seeing. For the power-user, the cheap and dirty way will
work... but a serious developer will always go this route, even though it is
considerably more of a pain.

Hope this helps! I think I finally got it...

--
Jack Leach
www.tristatemachine.com

"I haven''t failed, I''ve found ten thousand ways that don''t work."
-Thomas Edison (1847-1931)
 
W

WestWingFan

Ok, I did this. However,
- When the MsgBox pops up with the number and description:

- Hit Alt+F11 to open the vba window
When I hit Alt+F11 nothing happens. Nadda. So, I tried the cheap and easy
fix in your following post. I'll post the results of that there.
 
W

WestWingFan

Jack,

Thanks for hanging in there with me for this process. I tried the cheap and
easy way you suggest, but the error message for 2455 still appears. <rats!>
Maybe we have the wrong form? I'm back to being baffled. The error only
occurs when you exit this form in this way. If I exit other forms in this
way, they don't give the error.

I do have a split db with a hidden form that opens when the database does to
maintain the connection to the back end. I have read about using it to unload
the database before access closes, I'm not adverse to the idea, if it's the
only way to get around this. Which is sounding more likely.... Do you have
any other thoughts before I take this way? Thanks for all of your help so far
- it's been a great learning experience for me.
 
J

Jack Leach

I don't really have any other ideas. Let me verify though... this only
happens when you close the application - not when you close the form?

Do you have the Autocorrect option turned off by chance?


--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)
 
J

Jack Leach

Autocorrect is on. Should it be off?

Yes... turn it off. This is referred to as AutoCorrupt as well <g>

I'm not sure how that might effect this particular situation, but it should
be off anyway.

You can try importing everything into a fresh db (after you turn autocorrect
off again in the new one) and seeing if you still get the same results. If
that doesn't work then I don't have *any* ideas left. By the error
description it sounds like Access is trying to find a property on a form that
has already been closed... but we can't seem to catch it. Did you try
looping the Forms collection rather than using IsLoaded?

Anyway, that's I'll I have on it.

good luck...


--
Jack Leach
www.tristatemachine.com

"I haven''t failed, I''ve found ten thousand ways that don''t work."
-Thomas Edison (1847-1931)
 
W

WestWingFan

Oh, you mean Name Autocorrect - no I turned it off a year ago. <g>

I tried looping the forms collection - but to no good. It still produced the
error. Although the code is quite spiffy and much faster than the isloaded
function, so some good was done just by getting the IsLoaded out of my code.

So, out of desparation, I tried commenting out lines of code as I went. I
found I had a redunant requery of the subform in the Form_Load and Form_Open
events. When I commented out the form load - the error went away. So, I guess
we solved that one! Thanks for all your help and very detailed responses.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top