Full Version: Expression After Update Error
UtterAccess Forums > Microsoft® Access > Access Forms
I have an issue that would really like some insight on. I have a form with a series of comboboxes that filter information found on the form. What happens currently is when I select a value in any of the comboboxes I get an error:

The expression After Update you entered has the event property setting produced the following error: Object or class does not support the set of events.

*The expression may not result in the name of a macro, the name of a user-defined function, or [Event Prodecure].
*There may have been an error evaluating the function, event, or macro.

Now, when after getting this error I open the form in design mode, check things out from the control sources of the comboboxes to the code behind the After Update event procedures. Nothing seems out of place. I change nothing. I save the form and close. Go back into it in form view and everything works just like it should. I close the database, open it back up, go into that form and it all starts over again.

Is there something during the opening of the database that would cause this issue that somehow is corrected just by opening the form in design mode?

I would really like to get to the bottom of this because I really don't want to have to rebuild the form in question.

Final note: this doesn't happen in any of the other forms that have comboboxes in the database.
Those symptoms are typical of a database that needs to be decompiled (and recompiled).
Another thing to check for is that you don't have two objects with the same name ( A variable and procedure maybe?)
How does one decompile and recompile it? Never really got into that level on database development, even with writing code, I just allowed the program to handle everything.
Before decompiling, verify the code. Place Option Explicit at the top of each code module (below Option Compare Database) if it is not there already, and compile again. In the VBA editor go to Tools >> Options >> Editor tab, and check Require Variable Declaration to add Option Explict to the top of each new code module.

Also, see here for another potential source of problems.

If you do these things and there is still a problem, if you post the code here it may be possible to see something amiss. Another source of the error you mention is, for instance, trying to assign a value to a label rather than to its Caption property.
Ok, I have added the Option Explicit to the top of all the modules. How do I decompile?
Before we get to that, did you compile the code after adding Option Explicit?

Also, please post the code that is causing the error.
Well, I did close the database and reopened it. I am no longer having the issue, though the database takes longer to open.
If you haven't done a Compact and Repair recently, make a copy of the database, open the original, go to the Database Tools tab, and click Compact & Repair Database.

As for the slow speed, it could be any number of things. Does it run slowly, or is it slow to open but runs normally after that? Is there code in the startup form? Is it a split database with links to tables in a file at a network location? Is there a reason you don't want to post the code?

If you would like to try decompiling, UtterAccess Wiki has a number of helpful articles on a variety of topics, including this one about decompiling.
The code is rather simple. Except for one of the comboboxes, which actually will pull up a record, the others just requery the others based on what you enter into each combobox. I.E, 1 filters options for 2, 2 filters options for 3 and so on.

I have done a compact and repair recently (today) and everything seems to be working fine. Speed issues is really coming from two areas. One is that the server the database is housed is a little slow, especially during certain times of the day when bandwidth is being stressed by the number of users pulling information from that server. Not the same file, but many different files.

The database is split, and I do have code running in the start up form that grabs user information, but the delay I am experiencing is happening before that even loads. I will take a look at the decompile info and go from there.
I have a decompile shortcut on my desktop.
Open access with the shortcut, and it will then decompile whatever database you open with it.
Here is the 'target' line

"C:\Program Files (x86)\Microsoft Office\Office14\MSACCESS.EXE" /decompile

Maybe the C&R fixed the problem.
One of the things that can improve performance with little effort is to maintain a persistent connection to the back end database. I usually have a startup form from which the user can choose to open various forms and reports. I typically bind that form to a back end table, but without necessarily showing any fields from that table.
Not the same file, but many different files.

Many different database files, or many tables from one file, or a combination?
The server I mentioned just has a lot of verious files (word, excel, access, pdf, etc...) on it that many people use, which is why bandwidth is a cause of delay in opening things. That coupled with using laptops that were not designed to have as many applications open as we have.

Anyway, currently everything is working, but I would like to know the purpose and benefit surrounding de-compiling and recompiling a database.
Sometimes the 'machine' code gets a little bit corrupted. Not enough to stop everything working, but enough to cause a niggle.
A typical evidence of this is a process suddenly throwing up a new error, that doesn't seem possible.
Yours was a classic.
Other times it is a data issue, often with nulls and nothing to do with corruption.
What decompile does is to delete all the machine code, so when you then compile again, you get a full refresh.

Normally when you compile, Access doesn't re-to it all, but only the areas you've changed.

Decompile is a benign process. I've never known it to destroy a database, like compact can rarely(especially over a network).
So when I get an error like yours in an area I've not been working with, Decompile is my first port of call.
Because it's quick, easy, and safe, so I don't lose much time at all if that wasn't the problem, but save a lot if it is.
Whether decompile, compact and repair, or other repair efforts, a backup is the first step.

Another option that hasn't been mentioned here that I recall is to import all of the objects into a new blank database. My first step when creating a new database is to turn off Name AutoCorrect. The problems that feature can cause don't seem to be among the problems described in this thread, but it's worth mentioning.

I have rarely had benefit from decompiling and recompiling, but David makes a good point that it is an easy step with little risk of causing harm.
This is a "lo-fi" version of UA. To view the full version with more information, formatting and images, please click here.