>>>What you can do and it might help:
>>>1. Don't base your listboxes on cursors.
>>>2. Once your are done with populating it's own recordset, scan it and create a string.
>>>3. Assign the string as a rowsource for your listbox(es).
>>>4. Create a class module to handle this type of work, because you may re-use this technic later.
>>>
>>I'll try it when I get a chance. I have been pulled into other things to finish first. I'll let you know how it goes. Thank you.
>
>I'm coming back to the problem now. Would the string be limited to 65K characters? That would limit the number of items in the listboxes. I know we aren't supposed to have so many records in lists, but the user likes long lists. I could give them 50 or so at a time, and make it re-scan the form.recordsetclone when the next or previous 50 are needed. That will get complicated. I may post a separate question about the whole business of making a form "get the next few records".
>
>The form and listboxes are tied together. In the form.current, it sets the listbox.value = ID. In the listbox.click, it does a recordsetclone.findfirst "ID = " & str(currentlistboxvalue)
>
>Access 2002 can have a user-defined function in the listbox.RowSourceType. I suppose I could make the function scan the form.recordsetclone. The speed problem I am having pertains mainly to Access 2002 users. The question is whether the form can call the user-defined function quickly enough to make it worthwhile. I am reading up on it now.

Hi Bret,

If you have so much data to present in comboboxes, then you may reconsider using them for this particular form. What for do you use them on your form?