>>>>I've got a view that concatenates and formats lastname and firstname. It has around 15,000 names in it and it seems to take too long to load. There are no joins to the SQL statement. Any known tricks out there that might help speed the loading of this form. It is conceivable that in the future, this table will have over a million records in it and it is going to have to load quickly.
>>>>
>>>>The preference is to use views for everything to be able to switch between local and remote data. The views that are filtered and properly indexed for Rushmore run quick enough but the views that need an entire table load slowly.
>>>>
>>>>Thanks,
>>>>Steve Despres
>>>>EZ Data Inc
>>>>sdespres@erols.com
>>>
>>>Why not using parameterized local view ?
>>
>>Because the user is allowed to search for a "name" from the entire list of names in the view. The view populates a grid used for searching so all names must be available. In remote views, as Arnon suggested, one could play around with the FetchAsNeeded and FetchSize properties, (and we can blame response time on the network....*just kidding*), but for local views........it seems that it should process the table faster. I was just wondering if I was missing something. True, it does have to read, format and write all the names out, but with the potential for this table to contain over a million names, speed is important.
>>
>>Thanks,
>>Steve Despres
>
>I have a similar form with about 100,000 names in a grid based on a view. I concatenate first and last names in the recordsource of the grid column, not in the view itself. The form loads instantly. Is there a reason that you must concatenate in the view?
>
>Erik

Erik,

That's the kind of response I was sort of looking for. I'll experiment with setting up the grid as you suggested and try it on for speed. One issue for requiring the view to perform the concatenation is that this column is indexed for searching purposes. I should still be able to figure out how to index it. Right now, my grid assumes a single control source item.

Steve