E
eisaacs
I'm an experienced Access/VBA developer, but I've never seen this odd
behavior before. I've got an odd issue happening with one of my
comboboxes on a subform. When the form loads up, it works fine, but
on a requery the column(0) - column(x) values of the combo box become
NULL in code and the value doesn't display on the form, but the combo
box still has the original value AND the original value is in the
recordset of the combobox when you drop it down.
In the immediate window with another cbo I type:
?forms!frmSpecimen!subPanel.form.cboCompanyKey_Client.boundcolumn
1
?forms!frmSpecimen!subPanel.form.cboCompanyKey_Client
79
?forms!frmSpecimen!subPanel.form.cboCompanyKey_Client.column(0)
79
....79 is expected for column(0) and it works, but for this other
troubled cbo box all is not well...
?forms!frmSpecimen!subPanel.form.cboclientprogramkey.boundcolumn
1
?forms!frmSpecimen!subPanel.form.cboclientprogramkey
2
?forms!frmSpecimen!subPanel.form.cboclientprogramkey.column(0)
Null
?forms!frmSpecimen!subPanel.form.cboclientprogramkey.column(1)
Null
....all the column(X) values are NULL in code, but the cbo has a value.
Now the obvious thing would be if the recordset for rows after it was
requeried didn't didn't contain the value 2 for clientprogramkey, but
this is not the case. If I dropdown the list, that option is in the
available list within the rowset for the cbobox. If I select the
option, that record is then FIXED and both the cbo and column(0) show
value 2 from that point on, within the form and in code. If I close
the form and come back to that record, it works fine thereafter.
Other records are still messed up though and I'm not sure what is
triggering the issue.
This is how the cbo is being requeried, and the SQL is valid SQL that
results in the row in question and all the other applicable options
for that record at that time based on the other client cbo box's
value...
Me.cboClientProgramKey.RowSource = strSQL
Me.cboClientProgramKey.Requery
I've decompiled, compacted, and recompiled as well, but that hasn't
resolved the issue. Has anyone ever seen similar issues or a related
MS bug?
Thanks!
behavior before. I've got an odd issue happening with one of my
comboboxes on a subform. When the form loads up, it works fine, but
on a requery the column(0) - column(x) values of the combo box become
NULL in code and the value doesn't display on the form, but the combo
box still has the original value AND the original value is in the
recordset of the combobox when you drop it down.
In the immediate window with another cbo I type:
?forms!frmSpecimen!subPanel.form.cboCompanyKey_Client.boundcolumn
1
?forms!frmSpecimen!subPanel.form.cboCompanyKey_Client
79
?forms!frmSpecimen!subPanel.form.cboCompanyKey_Client.column(0)
79
....79 is expected for column(0) and it works, but for this other
troubled cbo box all is not well...
?forms!frmSpecimen!subPanel.form.cboclientprogramkey.boundcolumn
1
?forms!frmSpecimen!subPanel.form.cboclientprogramkey
2
?forms!frmSpecimen!subPanel.form.cboclientprogramkey.column(0)
Null
?forms!frmSpecimen!subPanel.form.cboclientprogramkey.column(1)
Null
....all the column(X) values are NULL in code, but the cbo has a value.
Now the obvious thing would be if the recordset for rows after it was
requeried didn't didn't contain the value 2 for clientprogramkey, but
this is not the case. If I dropdown the list, that option is in the
available list within the rowset for the cbobox. If I select the
option, that record is then FIXED and both the cbo and column(0) show
value 2 from that point on, within the form and in code. If I close
the form and come back to that record, it works fine thereafter.
Other records are still messed up though and I'm not sure what is
triggering the issue.
This is how the cbo is being requeried, and the SQL is valid SQL that
results in the row in question and all the other applicable options
for that record at that time based on the other client cbo box's
value...
Me.cboClientProgramKey.RowSource = strSQL
Me.cboClientProgramKey.Requery
I've decompiled, compacted, and recompiled as well, but that hasn't
resolved the issue. Has anyone ever seen similar issues or a related
MS bug?
Thanks!