Very Weird Problem (1 Viewer)

[Emma35]

Ok so i managed to get the form in question to open. In the OnOpen event of this form, there was a snippet of code which simply closed the previous form to keep things neat. When i removed this code everything started working again ??. This is the code

DoCmd.Close acForm, "Frm_SearchMulti", acSaveYes

I cannot for the life of me understand how this piece of code was causing that issue. Maybe you guys can see something odd that i'm missing

 

[Minty]

Not easily, unless there was something in the close event of that form, that would get triggered by it closing...

Also, just as a FYI the , acSaveYes switch is almost certainly redundant.
It forces a save of any design changes to the form, not anything to do with saving data that might have been entered on the form.

 

[CJ_London]

review the documentation

AcCloseSave enumeration (Access)

Office VBA reference topic

learn.microsoft.com

you are requiring the form to be saved (i.e. is the form, not the data). If your users are sharing the same FE, saving is not possible.

In any event, your users should not be making design changes to the forms. just remove the last parameter

 

[Emma35]

Not easily, unless there was something in the close event of that form, that would get triggered by it closing...

Also, just as a FYI the , acSaveYes switch is almost certainly redundant.
It forces a save of any design changes to the form, not anything to do with saving data that might have been entered on the form.

Thanks Minty....yes the OnClose event had code which was the reverse of the code above (it opened the form Frm_SearchMulti)

 

[Emma35]

review the documentation

AcCloseSave enumeration (Access)

Office VBA reference topic

learn.microsoft.com

you are requiring the form to be saved (i.e. is the form, not the data). If your users are sharing the same FE, saving is not possible.

In any event, your users should not be making design changes to the forms. just remove the last parameter

I wasn't aware that parameter was for saving design changes....i thought it was data. Yes i'll remove it and replace the code and see if it works. Thank you

 

[CJ_London]

if something doesn't work as you expect, always worth reviewing the documentation

 

[Pat Hartman]

I wasn't aware that parameter was for saving design changes....i thought it was data.

Access always saves the data, if it has been modified whenever the form is closed (other situations also). Most people have trouble STOPPING Access from saving bad data because they put their validation code in the wrong events.

In the OnOpen event of this form, there was a snippet of code which simply closed the previous form to keep things neat.

Poor practice. This means that you always need to know exactly what form opened the current one which makes it awkward for forms that can be opened directly from the menu as well as from another form or even worse, from multiple other forms.
Best practice. On the line after you open the new form, close the opening form if you have no intention of going back. In my apps I generally want to return to the opening form once the popup is complete so I open the second form a a dialog so I can stop the opening form's code from running. Then on the line before the openForm action, I hide the current form. In the open args, I pass in the name of the calling form.
Me.Visible = False
Then I open the second form as a dialog. When the second form is done and ready to close, I use the value in the openargs to open the calling form. That just unhides the original form AND more importantly, code resumes on the line after the OpenForm action. This allows me to requery the original form if the second form might have made data changes or added new records.

If you don't open the second form as a dialog, code continues executing after the OpenForm until the end of the procedure so you don't have control at the right spot when the called form closes to requery and capture any changes. This causes developers to try to make the second form automate the calling form and we're back to issues with the first form being closed,etc.

 

[gemma-the-husky]

Maybe the form wasn't open, so your code errored, and your database somehow got into a loop that you were unable to break..

 

[Emma35]

Access always saves the data, if it has been modified whenever the form is closed (other situations also). Most people have trouble STOPPING Access from saving bad data because they put their validation code in the wrong events.

Poor practice. This means that you always need to know exactly what form opened the current one which makes it awkward for forms that can be opened directly from the menu as well as from another form or even worse, from multiple other forms.
Best practice. On the line after you open the new form, close the opening form if you have no intention of going back. In my apps I generally want to return to the opening form once the popup is complete so I open the second form a a dialog so I can stop the opening form's code from running. Then on the line before the openForm action, I hide the current form. In the open args, I pass in the name of the calling form.
Me.Visible = False
Then I open the second form as a dialog. When the second form is done and ready to close, I use the value in the openargs to open the calling form. That just unhides the original form AND more importantly, code resumes on the line after the OpenForm action. This allows me to requery the original form if the second form might have made data changes or added new records.

If you don't open the second form as a dialog, code continues executing after the OpenForm until the end of the procedure so you don't have control at the right spot when the called form closes to requery and capture any changes. This causes developers to try to make the second form automate the calling form and we're back to issues with the first form being closed,etc.

Thanks a lot Pat....it never occurred to me to simply hide the initial form. Sounds like a much cleaner way of achieving the same outcome with less risk of causing this kind of error in future.

 

[Emma35]

Maybe the form wasn't open, so your code errored, and your database somehow got into a loop that you were unable to break..

Yes i think my sloppy use of the OnOpen and OnClose events may have caused this. Still, i'll make a note of it and not repeat the same thing again

 

[Emma35]

Thanks everybody for the help and suggestions as always.

Em x

 

[gemma-the-husky]

Error 2501 is a generic "There was a problem" which could be anythnig

in your open even if you added an on error statement it ought to ignore the close statement if there is no such form to close.
It depends whether you really so need that closeform operation. I know you removed the code, but ig you did need it, you can include simple error handling.

You always need error handling when interacting with objects, just in case.

Here it doesn't matter if the form isn't open, but you can't always igonre errors.

on error resume next
DoCmd.Close acForm, "Frm_SearchMulti"

 

[Pat Hartman]

@Emma35 You're welcome. Here's a sample that shows the code I use to "chain" forms.

Chaining Forms

Many people open multiple forms at one time. This is especially prevalent when you are using the tab view which is the default. I find that to be confusing for users so I developed a simple technique that uses the OpenArgs to allow one form to open another in DIALOG mode and then hide itself...

www.access-programmers.co.uk

 

[Emma35]

Error 2501 is a generic "There was a problem" which could be anythnig

in your open even if you added an on error statement it ought to ignore the close statement if there is no such form to close.
It depends whether you really so need that closeform operation. I know you removed the

You always need error handling when interacting with objects, just in case.

on error resume next
DoCmd.Close acForm, "Frm_SearchMulti"

Thank you. I actually tried that code but the error was still coming up. Actually i've put some of Pat's code in instead of what i had and the error doesn't happen anymore. I'm now getting a different error when i move on to the next form. I think this database might have had it

 

[Emma35]

@Emma35 You're welcome. Here's a sample that shows the code I use to "chain" forms.

Chaining Forms

Many people open multiple forms at one time. This is especially prevalent when you are using the tab view which is the default. I find that to be confusing for users so I developed a simple technique that uses the OpenArgs to allow one form to open another in DIALOG mode and then hide itself...

www.access-programmers.co.uk

Thanks again Pat...i'll use this method in future

 

[Isaac]

Error 2501 is a generic "There was a problem" which could be anythnig

in your open even if you added an on error statement it ought to ignore the close statement if there is no such form to close.
It depends whether you really so need that closeform operation. I know you removed the code, but ig you did need it, you can include simple error handling.

You always need error handling when interacting with objects, just in case.

Here it doesn't matter if the form isn't open, but you can't always igonre errors.

on error resume next
DoCmd.Close acForm, "Frm_SearchMulti"

I think every programming language needs stuff like Close If Open __ such as T-SQL has Create Or Alter Procedure, and Drop Table If Exists

Talk about making it easy!

 

[Pat Hartman]

Most of the time it is safe to trap the 2501 error and ignore it. But it really depends on what you're doing.