Bob,

>Here's the problem... imagine your scenerio... but, instead of one SalesRep foreign in the main table, there are 7. Also, each relation contains 3,000 possible choices... so, 3000 X 7 = 21,000 records you pull in just to display this form.<

I'm not sure I understand the scenario you describe where the combo box wouldn't work. Are you basically talking about multiple sales reps for a given customer? The solution I described, I use where there is a code of a particular type in the main table and I want the user to see the description or possibly the code and description. If the customer had 7 sales reps assigned to him, I would use a grid or listbox to display the choices.

If the purpose of a control is searching for a customer, I will always use a grid due to not knowing how large the customer file will grow. I've had to fix systems where someone used arrays for all the lookups. Then after the customer file grows sufficiently large, everyone starts getting insufficient memory errors.

>2. A combobox that as is said above is based on a query into an array. In the init, only the matching choice is pulled in... if the user pulls down the combo, a new query is done that includes all the choices... sort of delayed instantiation.
>

How do you implement the delayed instantiation. This is a good idea that I have not employed, but see the use for it. The only problem though, with delayed instantiation, is how does the query run if someone just enters the value into the combo. I am currently in the process of updating a system. I did not develop the old system. One of the things that bothers me about the existing system, when I watch someone use it, is that they constantly have to use the mouse because many fields have to be selected from list boxes. I have set up my combo boxes so if someone knows the code, they can enter it in the combo and incremental search will validate it. In this case the query has to have been done when the cursor is in the control.

>BOb