Thought I had conquered the Cascading "beast" however ...


Updating this cbo Results in:


Have the following References checked:
VB for Applications
MS Access 14.0 Object Library
OLE Automation
MS Office 14.0 Access db engine Object Library
What else do I need to do or try?

Hi Cynthia (IMG:style_emoticons/default/wavehi.gif)

Can't see much wrong with the code except you do not need the vbcrlf, and you can change the reference to cboempposition

Try:


hth

I haven't gotten that particular error before, but sometimes I get other weird errors I can't decipher that start with "The expression AfterUpdate you entered as the event property setting produced the following error:"...

When I do, I cut out my whole procedure, save it, then paste it back in and save it again, and then it magically works. Worth trying.

After looking deeper, why do you even set the rowsource in your code? Why don't you just assign that to the rowsource property directly and save it that way?

Hi Bernie! (IMG:style_emoticons/default/wavehi.gif)

Hi Todd! (IMG:style_emoticons/default/wavehi.gif)


Tried Todd's suggestion, which did get rid of the error msg,-- Thanks, Todd!!

Thanks Bernie, however, the cboSupervisor still isn't getting its RowSource from the strSQL. (IMG:style_emoticons/default/iconfused.gif)
cboSupervisor is a bound control-- but that shouldn't make a difference should it?

Sometimes what seems like it should be simple, trips me up! (IMG:style_emoticons/default/laugh.gif)

Hi Cynthia

I'd have to see your db to see why it's not setting the rowsource, the implication is the problem is in


If you want to post your db, I'd be happy to take a look.

Todd's suggestion will of course work; I'd assumed, as you are dynamically loading the row source, that you needed to change either the criteria of the combo box or even, in some scenarios, the complete SQL. If the row source does not change then better to leave it fixed in the design, with an appropriate requery when the criteria changes or on the 'On Enter' event.

Cheers.

Forgot to mention that when you paste it back in, you might have to go back to the event property and double click there again to fill in the [Event procedure] if it disappeared.

Bernie,

This db is one I was trying to help an op get normalized.

The form is frmEmployees
on the Employee History tab.

I did notice another issue-- whenever I selected an Event, the code window opened,
but the Private_Sub etc and End Sub lines weren't present.
C & R'd, closed, re-opened-- same problem.

Imported everything into a new db--
The Private_Sub etc are now displayed--
pasted the code and am now getting another error.

I know that I've overlooked something simple with this AfterUpdate Event (IMG:style_emoticons/default/dazed.gif)
Sounds like I'm whining..maybe I need a nap!!! (IMG:style_emoticons/default/laugh.gif)

I get 'unrecognized database format' when i try to open it.

Hi Cynthia

Looking at the db, there is a combo control cboSupervisor on the same form as cboEmpPosition; should the code be simply:


Another possible problem is that if the Employee history is a continuous form cboSupervisor will only show an entry for records with the selected position.

hth

Thanks for taking a look, Bernie.

I'll give that a go, and let you know!!

(IMG:style_emoticons/default/thumbup.gif)

I'm leaving the UA office now for some shut eye (IMG:style_emoticons/default/sleeping.gif) will take a look in the morning!
Hope it goes well.

Hi Cynthia

I've taken another look at the db.

In the set up you have, then Todd's suggestion of having the row source hard wired is the appropriate implementation as the criteria for the position ID will change for each record. The way to handle this would probably be best handled by a combo requery in the 'On Enter' event of the combo box . The problem is that whenever an event is triggered you get the error message you described - whether or not there is code in the event.

I suspect that the sub form has been corrupted and will need to be redesigned from scratch.

I also noticed that the sub form event window did not have the Private_Sub etc and End Sub lines present. Investigating this resulted in the VBA code window returning a completely empty window, further adding to the suspicion that the db has become corrupted.

hth

Bernie,

Have simplified the subform design and it seems to work now.
Decided that it wasn't up to me to decide if cboPosition needed an AfterUpdate Event--
will wait to see if the op decides that something like this is needed.

C& Rd, Closed & reopened--
When I changed the view to single form, the Private_Sub etc and End Sub lines were present --Corruption? (IMG:style_emoticons/default/iconfused.gif)

re Todd's suggestion-- I missed that,(Sorry Todd (IMG:style_emoticons/default/blush.gif) ) thanks for pointing it out-- I'll give that a try!

Hi Cynthia


You shouldn't need to change between single or continuous form the VBA sub should still appear correctly,

Also if you 'hard wire' the SQL row source of the combo box, then that will avoid needing the 'cboPosition' to rewrite the row source of 'cboSupervisor' but you will still need to requery 'cboSupervisor' when you change the record or change 'cboPosition'. On my tests any event triggering resulted in the same error message as you had. So, yes, I still believe the db has some corruption!

hth