>>>>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?

They are listboxes, not comboboxes. The listboxes list a subset of the records in a table, and only some of the fields. You click on the listbox, and the form navigates to that record, displaying the other fields for that record, and also its related records in a subform. The listboxes are duplicating the function of a grid as used in Visual FoxPro or Visual dBase V. I am mandated to make the Access database work like the Visual dBase version which it replaces. The form works very well if the front and back ends are the same version of Access, and if it's over a LAN, not a WAN.

I have again been diverted to other tasks, so I haven't been developing this form lately. I have discovered that retrieving the records under these circumstances (over a WAN, with a 2002 front end and a '97 back end) is very slow even if I just write a simple, optimized query that returns one record, and open a datasheet.