Combox uses 'wrong' value list (2 Viewers)

Geirr

Registered User.
Local time
Today, 04:20
Joined
Apr 13, 2012
Messages
53
Hi all.
I believe i have somewhat a little stupid question, but I hope I have some understanding - I'm just totally stuck here.

The case is:
Two different combo boxes with the following setup:

cboBox1, Control Source to a valid field in underlaying table:
Row Source: "Horizontal";"Vertical"
Row S Type: Value list

cboBox2, Control Source to another valid field in underlaying table:
Row Source: "Power";"Signal";"High Volt"; Common"
Row S Type: Value list

In table both columns shows the correct data according to the Value lists. (added manually test data) Then, when creating the two mentioned combo boxes in the form, the cboBox2 are showing the value list from cboBox1. The cboBox1 are showing the expected values. I have changed the Row Source Type to Query, deleted the value list and the cboBox2 of course shows nothing in form view. Changing back to the values list mentioned above in Source and switching back to Value List, and the cboBox2 are back showing the value list from cboBox1 instead of the value list which are clearly made for cboBox2.

So, just for testing, changing the Control Source of cboBox2 to a third valid table field, and suddenly the correct value list are displayed inform view.
All three fields in the table are of nvarchar() type. All three are having some test data with the correct according to wanted value lists. Btw; created a third combobox for the third field in the table with a value list, and this is show correctly the value list...

Then - for the sake of testing, I switched the underlaying table field for cboBox1 and cboBox2 - and surprisingly, the value list in form view where also switching despite the fact both cboBox1 and 2 have the opposite value list (original) in the setup.

Backend is SQL server table.

Regards, Geirr.
 
Wait, how can a value list be based on a table? A value list is based on the embedded text values you directly give it in the list. You should use the value list dialog method to create the list and edit the list.
 
then avoid switching combo's or switching Row Source Type to avoid any anomaly.

"Now I Am Become Death, the Destroyer of Worlds."
 
Wait, how can a value list be based on a table? A value list is based on the embedded text values you directly give it in the list. You should use the value list dialog method to create the list and edit the list.
As I wrote, both combo boxes have value list as written in the message above, box 1; "Horizontal";"Vertical" and box 2: "Power";"Signal";"High Volt"; Common". But in form view, the box2 are showing the list from box1 - that's the problem...
 
then avoid switching combo's or switching Row Source Type to avoid any anomaly.

"Now I Am Become Death, the Destroyer of Worlds."
Hi.

I know my english is limited, but the switching was only done to force something to happen. When selecting back to correct type and source, the secondary combo box where showing the value list from the combo box1. And to be clear, the combox 1 have shown the correct value list all the time.
 
cboBox1, Control Source to a valid field in underlaying table:
Row Source: "Horizontal";"Vertical"
Row S Type: Value list

cboBox2, Control Source to another valid field in underlaying table:
Row Source: "Power";"Signal";"High Volt"; Common"
Row S Type: Value list
I was referring to what you said about the combo boxes being based on a valid field in the underlying table. That cannot possibly be true in the case of a value list.
 
I was referring to what you said about the combo boxes being based on a valid field in the underlying table. That cannot possibly be true in the case of a value list.
Control Source where set to valid fields in the underlaying table. The Row Source is the lists mentioned in my initial message, and the Row Source type as mentioned as Value List.
 
cboBox2, Control Source to another valid field in underlaying table:
Row Source: "Power";"Signal";"High Volt"; Common"
it's probably just a typo, but Common is missing an opening double quote - double-check your actual RowSource, just in case this is causing an issue (unlikely!)
 
it's probably just a typo, but Common is missing an opening double quote - double-check your actual RowSource, just in case this is causing an issue (unlikely!)
Hi.

Thanks, I've checked but the typo where only in the message.
And - to make the case even more rare - I changed the value list in combo box 1 to "Horizontal";"Vertical";"Non of above" - but still, the combo box 2 will show the original list from combo box 1 which was "Horizontal";"Vertical"...
The only way to get the combo box 2 to show the correct value list, is to change the control source to another table field... It's so rare the whole thing.

In fact I do not like value list, I'm much more happy with using table query on a table as row source, so I might reconsider the whole thing, and see if that will be a better solution.
 
If you still need help, consider posting a sample db showing the problem. Do those "valid" fields happen to be lookup fields as well?
 
This sounds like it may be a variation of the combobox zombies puzzle described on my website
That is an artefact of the Inherit Value List property which by default is set to Yes.
Its much easier for you to try it out than it is to explain what is going on:

 
I have never come across that one before Collin. Nice to know about that anomaly. When I run into strange stuff like that, I usually just import all the objects into a brand new database and it all disappears. There must be hidden system table that isn't getting fully emptied causing that issue.
 
I have never come across that one before Collin. Nice to know about that anomaly. When I run into strange stuff like that, I usually just import all the objects into a brand new database and it all disappears. There must be hidden system table that isn't getting fully emptied causing that issue.

Its surprising how rarely it causes issues.
Did you read the explanation of what is happening behind the scenes?
 
And the zombie phenomenon should not apply with SQLServer backend?

Perhaps we can track down issue with db. Make copy of frontend and import relevant tables.
 

Users who are viewing this thread

Back
Top Bottom