Form Dirty not firing

[JB]

I have a form that I enter and with the Load event I disable the Save
button. I want the button to appear as soon as the form is dirty. I
have done this before with no problems even with other forms in this
same application.

When I type in the first field, the Form Dirty event is not firing. I
have a msgbox statement in the Form_Dirty event and it never appears.
I have an AfterUpdate event on the first field and I test Me.Dirty in
that code. Me.Dirty is true in that test of the first field.

Why doesn't Form.Dirty fire? What do I need to look at that will help
me trace this issue? How can Me.Dirty=True and Form_Dirty not trigger?

I have a similar problem on this form when I save the record. I use
Me.Dirty=False to save the record but the Form_BeforeUpdate event does
not fire either? Is this because of some code on the form? Can the
form be corrupted?

 

[Mark A. Sam]

It does sound like corruption. Did you test it with another control besides
the first?

I would try creating a new DB, importting all of the objects into it then
try it. You could also make a new form and copy and paste the controls into
it a few at a time, testing the dirty property as you do it. The cause
could also be a corrupt control.

God Bless,

Mark A. Sam

 

[JB]

What is the best way to test for corruption and to correct it?

This application, I inherited it from another programmer, has been
very buggy and has crashed multiple times. I have not been able to
resolve many of the problems and they are on my "To Do" list. This is
a complex application with many forms, queries and tables in Access
XP. I need it to be stable for client delivery in two weeks and am
concerned that the errors and crashes I am dealing with may be related
to corruption but I want to be sure before I go down that path.

 

[John W. Vinson]

This application, I inherited it from another programmer, has been
very buggy and has crashed multiple times. I have not been able to
resolve many of the problems and they are on my "To Do" list. This is
a complex application with many forms, queries and tables in Access
XP. I need it to be stable for client delivery in two weeks and am
concerned that the errors and crashes I am dealing with may be related
to corruption but I want to be sure before I go down that path.

Check out the suggestions at

http://www.granite.ab.ca/access/corruptmdbs.htm

YOu'll certainly want to MAKE A BACKUP (some of the cleanup procedures can
ironically destroy databases)

Some steps:

Open the VBA editor and select Tools... References. Remove or resolve any
MISSING references.
Select Debug... Compile; fix any code errors. Iterate until no errors.
Use Tools... Database Utilites... Compact and Repair.

It may be appropriate to Decompile (see how on Tony's page).

It is sometimes necessary to create a new empty database and import everything
to get rid of rubbish that Compact and Repair misses.

John W. Vinson [MVP]

 

[JB]

I have already checked out the suggestions at the website you
mentioned. I could not tell if what I am experiencing is related to
error ridden code or corruption. I suspect corruption but wanted to
avoid that pain if I was unsure.

Backups are not a problem. I keep multiple copies as a history on two
different drives. I make a dup every few hours just in case as a
standard procedure.

There are no Reference issues. I have Compiled and do so frequently
after many code changes. I verified that all forms are set to Option
Explicit and added error handling to every procedure and function. I
have compacted and repaired many times. Every time the app crashed it
also forces me to do a backup and compact and repair again.

I guess my next step is to decompile. If that does not work how do I
determine if I need to rebuild the form that is causing the current
trouble versus rebuild the whole database in a new container?

 

[Allen Browne]

JB, a couple of other things to check out.

1. Double-check that the form's On Dirty property is set to:
[Event Procedure]
or your macro. Do the same for the form's BeforeUpdate property.
If the property is not set, the event procedure will not run.

2. Test if something else is dirtying the form.
If you dirty the form programmatically, the Dirty event does not fire in all
versions of Access. The easiest way is to set the form's Record Selectors
property to Yes. The Record Selector appears to the left of the record, and
when the form is dirtied, its icon changes to a pencil. If the pencil
already appears before typing, the reccord is already dirty.

The most common culprits are any code you may have in Form_Open, Form_Load,
Form_Current, Form_AfterUpdate, or Form_AfterInsert. You really must not
assign a value to a bound control in those events.

 

[JB]

Thank you. I will try these options.

I no longer think that my database is corrupt. I have followed all
prior instructions regarding decompiling and importing all items into
a new database. In my new database, the form that I had the most
trouble with is still blowing up and crashing the application. I don't
even know where to start since Access crashes and gives me the Access
must close message and makes me save a backup copy of the db. I know
originally the form was not this messed up but I have been changing so
much code all over that I have no idea if it was me or if it is
something else.

Any advice on where to start troubleshooting something like this?

JB, a couple of other things to check out.

1. Double-check that the form's On Dirty property is set to:
[Event Procedure]
or your macro. Do the same for the form's BeforeUpdate property.
If the property is not set, the event procedure will not run.

2. Test if something else is dirtying the form.
If you dirty the form programmatically, the Dirty event does not fire in all
versions of Access. The easiest way is to set the form's Record Selectors
property to Yes. The Record Selector appears to the left of the record, and
when the form is dirtied, its icon changes to a pencil. If the pencil
already appears before typing, the reccord is already dirty.

The most common culprits are any code you may have in Form_Open, Form_Load,
Form_Current, Form_AfterUpdate, or Form_AfterInsert. You really must not
assign a value to a bound control in those events.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users -http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

I have already checked out the suggestions at the website you
mentioned. I could not tell if what I am experiencing is related to
error ridden code or corruption. I suspect corruption but wanted to
avoid that pain if I was unsure.

Backups are not a problem. I keep multiple copies as a history on two
different drives. I make a dup every few hours just in case as a
standard procedure.

There are no Reference issues. I have Compiled and do so frequently
after many code changes. I verified that all forms are set to Option
Explicit and added error handling to every procedure and function. I
have compacted and repaired many times. Every time the app crashed it
also forces me to do a backup and compact and repair again.

I guess my next step is to decompile. If that does not work how do I
determine if I need to rebuild the form that is causing the current
trouble versus rebuild the whole database in a new container?

- Show quoted text -

 

[Allen Browne]

One step at a time.

If Access is being shut down by Windows, something is wrong, so it's a
matter of tracking down what. I can give you a sequence to follow but your
probably sick of that. Just double-check you have Name AutoCorrect turned
off in both the front end and the back end, that you have decompiled and
compacted after that, that you have minimal references, and your code
compiles okay.

If all that checks out, use the divide-and-conquor approach to pin down
exactly what is causing it to crash. Start jetisoning stuff until the crash
goes away, and then add it back until you pin down the culprit.

From your original message, my first guess is one of the 2 things suggested
in my last post.

--
Allen Browne - Microsoft MVP. Perth, Western Australia

Reply to group, rather than allenbrowne at mvps dot org.

Thank you. I will try these options.

I no longer think that my database is corrupt. I have followed all
prior instructions regarding decompiling and importing all items into
a new database. In my new database, the form that I had the most
trouble with is still blowing up and crashing the application. I don't
even know where to start since Access crashes and gives me the Access
must close message and makes me save a backup copy of the db. I know
originally the form was not this messed up but I have been changing so
much code all over that I have no idea if it was me or if it is
something else.

Any advice on where to start troubleshooting something like this?

JB, a couple of other things to check out.

1. Double-check that the form's On Dirty property is set to:
[Event Procedure]
or your macro. Do the same for the form's BeforeUpdate property.
If the property is not set, the event procedure will not run.

2. Test if something else is dirtying the form.
If you dirty the form programmatically, the Dirty event does not fire in
all
versions of Access. The easiest way is to set the form's Record Selectors
property to Yes. The Record Selector appears to the left of the record,
and
when the form is dirtied, its icon changes to a pencil. If the pencil
already appears before typing, the reccord is already dirty.

The most common culprits are any code you may have in Form_Open,
Form_Load,
Form_Current, Form_AfterUpdate, or Form_AfterInsert. You really must not
assign a value to a bound control in those events.

I have already checked out the suggestions at the website you
mentioned. I could not tell if what I am experiencing is related to
error ridden code or corruption. I suspect corruption but wanted to
avoid that pain if I was unsure.

Backups are not a problem. I keep multiple copies as a history on two
different drives. I make a dup every few hours just in case as a
standard procedure.

There are no Reference issues. I have Compiled and do so frequently
after many code changes. I verified that all forms are set to Option
Explicit and added error handling to every procedure and function. I
have compacted and repaired many times. Every time the app crashed it
also forces me to do a backup and compact and repair again.

I guess my next step is to decompile. If that does not work how do I
determine if I need to rebuild the form that is causing the current
trouble versus rebuild the whole database in a new container?

Check out the suggestions at

YOu'll certainly want to MAKE A BACKUP (some of the cleanup procedures
can
ironically destroy databases)

Some steps:

Open the VBA editor and select Tools... References. Remove or resolve
any
MISSING references.
Select Debug... Compile; fix any code errors. Iterate until no errors.
Use Tools... Database Utilites... Compact and Repair.

It may be appropriate to Decompile (see how on Tony's page).

It is sometimes necessary to create a new empty database and import
everything
to get rid of rubbish that Compact and Repair misses.

John W. Vinson [MVP]- Hide quoted text -

- Show quoted text -

 

[AccessVandal via AccessMonster.com]

Hi JB,

Have you start by checking what Allen posted?

There are things you need to know on “Form’s OnDirty Eventâ€
and the “Form’s BeforeUpdate Eventâ€.

1.The Form OnDirty Event, when it fires is always “Falseâ€. After the event is
over,
it will be “Trueâ€. Is there anything else that might cause the Form to change
to “False�

2.Form OnDirty Event will fire when a control is bound (not when is unbound).
Is
the control bound to a source? (your first control/TextBox).

3.Form Before_Update Event will not fire too if it is unbound.

 

[JB]

Thanks for the input. Today it is time to tackle the monster. I am
going to start commenting out everything that Access chokes on and see
what I have left. I am going to look at the issue of :

"The most common culprits are any code you may have in Form_Open,
Form_Load,
Form_Current, Form_AfterUpdate, or Form_AfterInsert. You really must
not
assign a value to a bound control in those events. "

I am also asking the programmer who worked on this before me to
evaluate what I am seeing and get some input from him. I think fresh
eyes and another perspective will help speed things up.

 

[JB]

I have solved part of my problem. I was working on some other related
matters. There were a variety of issues on this form that I have been
working through. I am now down to the final details.

Form Before_Update was not firing because the [Event_Procedure]
reference was not linked in the Form Properties. I do know how that
happened. I am using this event to validate fields that require data.
If a field is blank, I display a msgbox prompt, set the focus to the
blank field, and set Cancel=True. I believe that is right. My memory
is rusty.

My Save procedure triggers the Form Before_Update. After saving the
record, it uses SQL to add a record of data to another independent
table and then closes the form. I do not remember what to do to stop
the Save procedure from running the SQL and closing the form if the
Before_Update found a blank field and set Cancel=True.

Any help will be appreciated.