vba controls missing?

[kboldin]

Having a little issue with missing properties between work and home, both are the same access version from office 365. I think I'm missing a setting or reference but I've been looking and can't find it. I'm using a combo box selection to auto populate a form to automate redundant data entries. Anyway, my code wasn't working that I've written many times before, that's when I noticed the difference when troubleshooting. At home, I only get the value of my Me.product_id where at work I get many other property option. At home I get a compile error because it can't find "column". Seems like a setting that I'm not aware of, thanks for any advise in advance.

[June7]

Compare the library references selected in each.

[kboldin]

I did, verified they are the same.

[June7]

Well, that sucks! I am not aware of any other setting that would cause this. Sorry, I don't use 365. Is there another home computer running 365 you could test with?

[kboldin]

I do, I'm going to test in the morning when she goes to work Appreciate the help though!

[CJ_London]

in your work version the control is called cboloanappid, the home version the control is apparently called product_id - which implies a field name, not the name of a control. Further the function is called prod_id_change which implies the name of the control is prod_id.

In summary - are you sure you have the correct name for the combo control

[kboldin]

in your work version the control is called cboloanappid, the home version the control is apparently called product_id - which implies a field name, not the name of a control. Further the function is called prod_id_change which implies the name of the control is prod_id.

In summary - are you sure you have the correct name for the combo control

Yes, those are examples. The work is an actual Db is use, the home is a test file to see if could find out what's going on.

[kboldin]

I tested on another machine, same issue. Both machines share the same Office 365 license. We are on an annual subscription, don't think its a lesser version but I may be mistaken. This has helped to walk through the issue, appreciate the input. Any other idea's let me know!

[CJ_London]

So to be clear, your combo is called product_id and prod_id is a different control where you are running this code

[moke123]

Try adding Option Explicit to all your modules and see if your code compiles.
Your picture indicates its not there.

[kboldin]

To be clear, I'm an idiot.... PEBKAC strikes again. The control was wrong and I had to relearn a lesson from long ago. I don't believe Access likes the underscore naming convention. I write way more sql these days and havea habbit of using underscore for nearly every field. E.g. Product_id, prod_id etc.. When running a private sub in Access I don't believe Access knows what to do with Product_id_Change because of the double underscore, where ProductId_Change works like a champ. I do appreciate all the help, not sure why I went down the road I went LOL! Anyway PEBKAC!!!

[moke123]

I don't believe Access likes the underscore naming convention.
When running a private sub in Access I don't believe Access knows what to do with Product_id_Change because of the double underscore,

Not sure that's the problem.

Just tested with a combo named C_b_o_some_Combo and works as expected.

btw, Afterupdate is probably the more appropriate event for a combobox. If someone were to type in the combobox it would fire the onchange event.

[CJ_London]

Think the issue is not with the underscore per se. More to do with spaces in field/control names. Vba will replace a space with an underscore.

Personally I avoid underscores anyway -,they make long sql statements hard on my eyes. I prefer camel case

[moke123]

I prefer camel case

I'm with you there. The only problem is it carries over to my handwriting and non-coding typing too.

[Micron]

Personally I avoid underscores anyway -,they make long sql statements hard on my eyes. I prefer camel case

Another vote for camel case. Also, IMO it's best to use a less ambiguous naming convention. ALL my form controls are prefixed per type (e.g. cmb is combo) so there's never any doubt if a reference is a control or not. FWIW, .Value isn't even required as it's the default property of all (?) controls.