Form Recordset Head Scratcher

[gg]

Hi all,
I have a form who's rowsource is programatically modified based on an
options group. The query results in a 10 column list where the user is
allowed to choose only one from the list.


Example: the user is presented with an initial list (we will call them)
"open jobs" that is chosen from a combo box. If the user selects (from
the combo box) "closed jobs" the program will replace the list box's
rowsource to coincide with the new user selection and requery the
source to the list box. And the listbox returns the correct
information in all cases.


Now, I have been trying to access the user selection information in two
ways by referencing the column [me.lstbox.column(4)] and alternately
referencing the "presumably" same data using the field name
[me.lstbox.Recordset.Fields("fldName").


In debug:
Both sets of data are identical using either of the above methods.
UNITL I toggle one of the open/closed job elements in the combo box.
It seems that after a requery of the listbox the data is perfect when
selected with the "column" method and TOTALLY messed up with the
"recordset" method.


The problem seemingly occurs when a requery occurs and my guess is that
the recordset is not being managed properly.


My question:
1. Have any of you encountered this problem before and possibly
resolved it?
2. Since the problem NEVER occurs after Form_Load I h ave been trying
to find methods of closing the recordset and re-initializing it after
the requery takes place but have been unsuccessful. Can comeone here
give me some methods of accompishing this. I am not as proficient as I
would like to be, and therefore am requesting some help here.


Thanks in advance
GG

 

[Wayne Morgan]

I show that using the Recordset method of doing this is unreliable. If I
select the last visible item in the list (the one partially displayed at the
bottom of the listbox) the listbox moves up to fully display it but gives
the value of the next item in the list. If I scroll the list up select the
next item, it gives the next item below that. Once started, this continues
until I move back up the list, then it seems to reset itself and start
giving the correct answer again.

That being the case, I would consider this to be a bug and wouldn't use the
Recordset option.

 

[GusGG]

Wayne,

Thank You for confirming the problem for me.
I was thinking that I was missing something. And, since I could not find
anything on the topic it made me more concerned that I was not understanding
the functions properly.

Anyway, is there a forum where these bugs are listed, or is it up to the
individual to "google for answers"? Thanks again for the help.
gg

I show that using the Recordset method of doing this is unreliable. If I
select the last visible item in the list (the one partially displayed at the
bottom of the listbox) the listbox moves up to fully display it but gives
the value of the next item in the list. If I scroll the list up select the
next item, it gives the next item below that. Once started, this continues
until I move back up the list, then it seems to reset itself and start
giving the correct answer again.

That being the case, I would consider this to be a bug and wouldn't use the
Recordset option.

--
Wayne Morgan
MS Access MVP

Hi all,
I have a form who's rowsource is programatically modified based on an
options group. The query results in a 10 column list where the user is
allowed to choose only one from the list.


Example: the user is presented with an initial list (we will call them)
"open jobs" that is chosen from a combo box. If the user selects (from
the combo box) "closed jobs" the program will replace the list box's
rowsource to coincide with the new user selection and requery the
source to the list box. And the listbox returns the correct
information in all cases.


Now, I have been trying to access the user selection information in two
ways by referencing the column [me.lstbox.column(4)] and alternately
referencing the "presumably" same data using the field name
[me.lstbox.Recordset.Fields("fldName").


In debug:
Both sets of data are identical using either of the above methods.
UNITL I toggle one of the open/closed job elements in the combo box.
It seems that after a requery of the listbox the data is perfect when
selected with the "column" method and TOTALLY messed up with the
"recordset" method.


The problem seemingly occurs when a requery occurs and my guess is that
the recordset is not being managed properly.


My question:
1. Have any of you encountered this problem before and possibly
resolved it?
2. Since the problem NEVER occurs after Form_Load I h ave been trying
to find methods of closing the recordset and re-initializing it after
the requery takes place but have been unsuccessful. Can comeone here
give me some methods of accompishing this. I am not as proficient as I
would like to be, and therefore am requesting some help here.


Thanks in advance
GG

 

[Wayne Morgan]

I don't know of a single location to find a list of these. I did some
further checking and it appears that using the combo box's Recordset this
way is an "undocumented feature". This means that if it works for you,
great, but since it's not mentioned, it's not promised to work. It also
means that it may not work in the next version or versions down the road
sometime. Programmers run into this all the time when they find some dll
file will do something that's not advertised. When a new version of the dll
changes this, it breaks their application.

--
Wayne Morgan
MS Access MVP

Wayne,

Thank You for confirming the problem for me.
I was thinking that I was missing something. And, since I could not find
anything on the topic it made me more concerned that I was not
understanding
the functions properly.

Anyway, is there a forum where these bugs are listed, or is it up to the
individual to "google for answers"? Thanks again for the help.
gg

I show that using the Recordset method of doing this is unreliable. If I
select the last visible item in the list (the one partially displayed at
the
bottom of the listbox) the listbox moves up to fully display it but gives
the value of the next item in the list. If I scroll the list up select
the
next item, it gives the next item below that. Once started, this
continues
until I move back up the list, then it seems to reset itself and start
giving the correct answer again.

That being the case, I would consider this to be a bug and wouldn't use
the
Recordset option.

--
Wayne Morgan
MS Access MVP

Hi all,
I have a form who's rowsource is programatically modified based on an
options group. The query results in a 10 column list where the user is
allowed to choose only one from the list.


Example: the user is presented with an initial list (we will call them)
"open jobs" that is chosen from a combo box. If the user selects (from
the combo box) "closed jobs" the program will replace the list box's
rowsource to coincide with the new user selection and requery the
source to the list box. And the listbox returns the correct
information in all cases.


Now, I have been trying to access the user selection information in two
ways by referencing the column [me.lstbox.column(4)] and alternately
referencing the "presumably" same data using the field name
[me.lstbox.Recordset.Fields("fldName").


In debug:
Both sets of data are identical using either of the above methods.
UNITL I toggle one of the open/closed job elements in the combo box.
It seems that after a requery of the listbox the data is perfect when
selected with the "column" method and TOTALLY messed up with the
"recordset" method.


The problem seemingly occurs when a requery occurs and my guess is that
the recordset is not being managed properly.


My question:
1. Have any of you encountered this problem before and possibly
resolved it?
2. Since the problem NEVER occurs after Form_Load I h ave been trying
to find methods of closing the recordset and re-initializing it after
the requery takes place but have been unsuccessful. Can comeone here
give me some methods of accompishing this. I am not as proficient as I
would like to be, and therefore am requesting some help here.


Thanks in advance
GG

 

[Wayne Morgan]

I did some more checking and while the exact usage of the listbox's
recordset isn't mentioned this way, I think that there is enough mentioned
to consider this as a bug. I have reported it, we will see what happens.

 

[GusGG]

Once Again,
Thanks Wayne for all your detective work on this.
To me this seems a rather straightforward issue of a bug.
But, since I am rather new at Access i tried to follow the logic tree and
that is how I arrived at the error.
MS has given many different routes to get at the same information. And in
my attempt to make my app transportable to other platforms I usually find
these obscure hiccups. My biggest cosncen was that the underlying data
(however accessed) could be corrupt. But you have put my mind at ease on
that.

Thanks again, and keep me informed if you hear anything more.
gg