Here's the 'Help' page:This component doesn't support this set of events (Error 459) Not every component supports client sinking of events. This error has the following cause and solution:You tried to use a WithEvents variable with a component that can't work as an event source for the specified set of events. For example, you may be sinking events of an object, then create another object that Implements the first object. Although you might think you could sink the events from the implemented object, that isn't automatically the case. Implements only implements an interface for methods and properties. You can't sink events for a component that doesn't source events.WithEvents isn't supported for Private UserControls, because the type-info needed to raise the ObjectEvent isn't available at runtime. ______________Here's the line that gives the error:Private Sub Form_Current()Forms!StartHere!ItemPricing.Form.Filter = "PRODITEMID = " & ProdItemID________The form calling the code is a subform in 'StartHere', named 'ProductItems'; 'ItemPricing' is another subform in 'StartHere'; ProdItemID is a field in the recordset and a bound control in 'ProductItems', and a field in the recordset of 'ItemPricing'._________Can anyone make a connection for me between the procedure, the error, and the explanation? i.e., Is there a translation of this 'Help' in my native language?

>I speak English and it ain't English.ry:Me.Parent!ItemPricing.Form.Filter = "PRODITEMID = " & Me.ProdItemIDNote: when you type the second Me.a listbox should pop up andProdItemIDshould be in the list.

...It ain't English...whew!, thought it was me...I'll try the new syntax. The error just comes up every so often, and if I Debug>Compile (no errors) it's OK again. I'm in the habit of Compiling each time I change code & don't remember neglecting to do so, but the compile menu item is always available when this happens.

Hello and thank you for this post. This error was driving me crazy, but this post helped me to figure out what was going on with my database. My database was running fine for a long time. My manager asked me to change a form. This caused me to change the database in a major way. I had to create 2 more tables and delete some fields from a table. Those fields wound up being split up into the new tables that I created. I was taking a form that had no subforms and creating 2 subforms on it. That meant that I was deleting some controls from the original form. I had originally written some code that involved the controls that I deleted. However, when I deleted the controls from the form and added my 2 new subforms, I forgot to go into the code for the now parent form and delete the code for the controls that no longer existed. So, whenever I clicked one of the affected controls, the code was trying to execute, but it was invalid. Instead of telling me that in plain English, I got this rediculous error. So, I deleted all of the old code and recompiled the form and no more stupid error. Thanks again for the post.avid

Searching the forum for "Error 459" with MS-Access 2007 turned up this thread for me. While my circumstances didn't quite match others described here, something in the thread clicked for me and brought me to the fix. I still don't know exactly what caused my problem but maybe describing it and my fix will click for someone else and save them some grief. My code had been running for quite a while but started failing when an old, reliable function was invoked from a sub-form (Sound familiar, bqmsd and EngNate?). The failing line of code was:

This line and several others are executed within a For KeysX = 0 To UBound(Keys()) loop to build a WhereCondition option for a following DoCmd.SearchForRecord instruction. As you might guess, Keys() is a ParamArray passed to the function with Control names in the even numbered array elements and their values in the odd numbered elements; each even-odd pair forms a search argument. The fix was to simplify the failing line of code to:

WhereCond = WhereCond & Keys(KeysX) & "="

and, of course, change all 40+ invocations of the function to pass the Control Source name instead of the Control name. Obviously, I had forgotten to KISS. The confusing part of debugging this problem, besides the unintelligible documentation of Error 459, was that it failed consistently until I entered Debug mode and executed the immediate instruction:

? Forms(DetailForm).Controls(Keys(KeysX)).ControlSource

The code would then run perfectly so long as I remained in Access. If I shut down Access and restarted it, Error 459 appeared again until I entered Debug mode as described above (I suspect other immediate instructions might have cleared the problem but I didn't try others). Incidentally, I tried forcing a compile. That didn't help and neither did a "Compact and Repair".At this point, I believe we have encountered a bug deep within Access. If I were going to debug this, I'd start by looking for a bit that is turned on to indicate more than one condition. Good luck with that! Having found an acceptable fix, I'm going to try to ignore it. If Microsoft or anyone else wants to look at my code to try to get to the bottom of this, let me know.

Well Chuck, the main thing is that something in this post triggered the solution in your mind. Maybe Microsoft should hire Access users to write their documentation instead of Microsoft company employees.incerely,David