check for field in record not empty

[jtan]

I've a form with about 30 fields for user to key in the data, a close form button and a save record button.
If user key in any one of the fields and click close form button, Access to prompt user whether to save record or not


Instead of using If condition to check Is not null for every field, is there a quick way to check for any field in record is not empty?

[June7]

You could test if the record is dirty but this won't tell you which field is causing dirty status.

If Me.Dirty Then

[jtan]

Thanks June7 for your prompt reply.

But Me.Dirty does not work
The 30 fields in the form are unbound fields. User open this form to enter new record. When user open and close form without keying data in any field, clicking the "close form" button will close the form immediately.
When user key in data in any field, Access will prompt user whether to save record or not.
Any help, please

[Bob Fitz]

You could use code to loop through each of the forms controls and test each one for a null

[June7]

Why use unbound form?

[Missinglinq]

Using Unbound Forms really does away with the basic function of Access, which is to facilitate RAD (Rapid Application Development) and should only be attempted by very experienced Access developers, and then only when/if a legitimate purpose requires it, and most situations don’t! You don't need Unbound Forms to do

1. Data Validation
2. Formatting Data before it's Saved
3. Deciding whether or not to actually Save a New or Edited Record

which are the most common reasons given. Nor are they needed for another dozen reasons I've seen people give!

Several developers I know, experienced in Visual Basic database development and Access development, estimate that development, using Unbound Forms, by highly experienced developers, takes two to three times as long, using Unbound Forms, as it does when using Access and Bound Forms. That’s because with Bound Forms the Access Gnomes do the vast majority of the heavy lifting; with Unbound Forms the developer has to write code for everything...even the most mundane tasks!

Bottom line is…with Bound Forms you end up writing code for a few specialized situations, such as #1-#3, as listed above…and with Unbound Forms you have to write code for virtually everything that needs to be done!

If you insist on using Unbound Forms, you'd be far better off using a straight VB or C++ front end with a SQL Server or Oracle back end.

• You can create an EXE file which gives total protection to your code/design
  
• You can distribute the db to PCs without a copy of Access being on board
  
• Your data security is far, far better than anything you can do in Access

Don't misunderstand me...there are a few, specialized situations, where an Unbound Form is preferable...but anyone who routinely uses them for everything, has simply made a bad choice in deciding to work in Access.

Linq ;0)>

[moke123]

Heres a similiar situation with a solution along the lines of what Bob suggested
https://www.accessforums.net/showthr...500#post462500