How to make a notification when forget to enter the date in the form of access ? (1 Viewer)

[kanxay]

I have a form with date entry ! And I want to make alert when forget to enter the date ? How can I do ???

 

[Ranman256]

you can set the VALIDATION RULE property on the text box to NOT ISNULL(txtbox)
but for many field checks I run code to see if everything was done right:

usage:
sub btnSave()
if not IsValidForm() then exit sub
'....process code here
end sub

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

 

[theDBguy]

I have a form with date entry ! And I want to make alert when forget to enter the date ? How can I do ???

Hi. Have you tried making the date field a required field at the table level?

 

[Ranman256]

yes Reqd field on textbox would be easiest.
you can also help them by setting default value= DATE() , if that is a good default date.

 

[HiTechCoach]

I agree with theDBguy.

When it is critical for a field to contain data, then I set it as required at the table’s field level.

If you set the field as required at the table level, there is no way to avoid entering the data. Even if someone were to manually enter data directly into the table, it will require the filed to have data. Access will automatically display a message if you do not use any error-trapping code.

In addition, to make the UI more friendly, I also like to use the Form's Before Update event to do form level validation. By using this event, it will always "fire" before the record is saved. It does not matter how the save is triggered the save.

 

[zeroaccess]

In my experience, setting a field to required in the table will result in:

• 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.

So you need to do a little more at the form level.

 

[theDBguy]

In my experience, setting a field to required in the table will result in:

• 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.

So you need to do a little more at the form level.

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.

 

[zeroaccess]

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.

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.

 

[theDBguy]

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.

Are you able to post a demo to show the behavior you're seeing? Just curious to see it...

 

[Micron]

I couldn't close the form or go to a new record without having to acknowledge the missing data.

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.

 

[zeroaccess]

Are you able to post a demo to show the behavior you're seeing? Just curious to see it...

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.

I will say that validation works as others describe here. Say if you don't allow null in a field, and a user deletes the default 0, it will bark at them and not allow them to move until they enter a value. But a field I tried setting to required did not result in any prompt if skipped - only if something attempted to be entered, and the user bailed or deleted what was entered were they required to complete the field.

 

[HiTechCoach]

I assume that you are not using the Before Update event of controls or the form to do any validation. I use the Beoifer Update event besue I can provide a better user experience with my own messages and other UI features.

I use the database engine rules as a safeguard.

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 indicates that you have suppressed or trapped the error message in some way.

EDIT: Also how we set our recordsource may matter...not sure.

It has nothing to do with how you set the form's record source. Setting a field to do not allow nulls and required in the table design is enforced by JET/ACE (the database engine), not Access (MSACCESS.EXE).

FYI: Access is really just a front end. Access's default database engine is JET/ACE. and the MDB/accdb format.

 

[kanxay]

i can not upload the .accdb file , so i only post the picture like this , please some one explain clearly because i do not have basic about VBA access

 

[missinglinq]

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)>

 

[jdraw]

We will explain once you describe exactly what the issue is using the form you have posted as example.
Exactly which control on this form MUST be valued before the record can be accepted?
Go to the underlying table in the form's recordsource and make that field "required" by adjusting the Required property.

 

[zeroaccess]

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)>

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...

...unless you're missing a required field? Is that what's going on?

 

[missinglinq]

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.

Linq ;0)>

 

[zeroaccess]

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.

What an odd quirk of Access. Well, now we know. Thanks.