Private Function IsValidForm() As Boolean
Dim vMsg
Select Case True
Case IsNull(txtWeek)
vMsg = "Date field missing"
Case IsNull(cboUser)
vMsg = "Teacher name is missing"
Case IsNull(cboSubj)
vMsg = "Subject field is missing"
End Select
If vMsg <> "" Then MsgBox vMsg, vbCritical, "Required Field"
IsValidForm = vMsg = ""
End Function
Hi. Have you tried making the date field a required field at the table level?I have a form with date entry ! And I want to make alert when forget to enter the date ? How can I do ???
That's interesting. I just tried it, and I couldn't close the form or go to a new record without having to acknowledge the missing data.In my experience, setting a field to required in the table will result in:
So you need to do a little more at the form level.
- If User skips the required field on the form and closes the form, they will receive no error message and it will not be saved. The User will not understand why they can't find the record they just created.
I've only tested this with one form. It's possible we could see different behavior. So I should say YMMV and make sure you test it.That's interesting. I just tried it, and I couldn't close the form or go to a new record without having to acknowledge the missing data.
Are you able to post a demo to show the behavior you're seeing? Just curious to see it...I've only tested this with one form. It's possible we could see different behavior. So I should say YMMV and make sure you test it.
EDIT: Also how we set our recordsource may matter...not sure.
FWIW, that has always been my experience. You get at least one system message and have to decide whether or not to continue and lose the record or stay and complete it.I couldn't close the form or go to a new record without having to acknowledge the missing data.
I can't at this point in time. The form relies on a lot of other parts that can't be detached for demo use. At some point, maybe.Are you able to post a demo to show the behavior you're seeing? Just curious to see it...
That indicates that you have suppressed or trapped the error message in some way.I've only tested this with one form. It's possible we could see different behavior. So I should say YMMV and make sure you test it.
EDIT: Also how we set our recordsource may matter...not sure.
This is interesting - I am using DoCmd.Close, but it's an .accdb. I don't use the "dirty" code on close as it's unnecessary. Records will save automatically...Perhaps in the past @zeroaccess has been using the Command Button Wizard or the code
DoCmd.Close
to close his forms.
In pre-2007 Access, if you used the wizard or the above code to close forms...'required fields' unpopulated were simply ignored and the form would close, dumping the errant Record.
In 2007, the Boys of Redmond revised the wizard's code to read
If Me.Dirty Then Me.Dirty = False
DoCmd.Close
which fixed the problem. Of course, if you now use the wizard to create a 'close' button for an Unbound Form, the first line will now cause an error!
Linq ;0)>
What an odd quirk of Access. Well, now we know. Thanks.Exactly! So by adding the
If Me.Dirty Then Me.Dirty = False
before the
DoCmd.Close
you force the Save...and if required data is missing...it'll be caught.