>The complex view I posted is for read-only purposes. When updating or adding data usually only one table is affected. And btw, I do have total control over the data structures.

ok this paints the picture in a better light then...

>On the other hand, if I break up the single view into 3 cursors as I showed, the delay will be shortened to under 1 second.

I've done this before in similar situations so I wouldnt think your too off base here. You might want to look at spreading the load around a little and have some cursors created at startup under the guise of the splash screen, then create your final cursor to drive the combo when the form is launched.

>My [rookie} question here is whether I'm supposed to tweak these things the way I'm proposing or is there something else that I'm missing?

About the only thing I havent seen you propose is a view based on a view, which I've also done on rare occaision but only when I'm dealing with a read-only lookup data. This is similar to your approach with breaking the query down in multiple cursors expect done entirely with views. You can make use of the framework's example for indexing a view to get better performance to too. Note - There are those up here who strongly advise against this (I belieive if you do a search Erik Moore has posted some really good arguments against it that I refer to before going this route).


>Could you please explain why you say these two?

the additional info you gave me in last response pretty much negates the grounds for those comments... < g > nebbermind


>A number of the fields in these tables come from comboboxes where the user can choose from a list or also type a new option, so we ended up with "X-RAY", "X-Rays", "X RAY", "X RAYS", etc. I created queries to extract unique data from these fields to populate MY combos and that's how I ended up with those huge sets of choices. Of course, once we migrate, they will start cleaning all this up and hopefully my combo's will go down to reasonable 20-50 choices, which is really all they need.

so your performance concerns are only for an intermediate time period until the data is cleaned up? That's not pretty, you do all this work now to make your combo's faster, then the data sources get cleaned up and it's overkill. Sounds like you need some data migration policies/standards setup here... Have you considered writing a prg that can pull the original data into a form more suited to your app's needs? I've done this often when migrating tables from one platform to another, I use the prg to populate data for development effort then re-use it as a batch process when the app goes live.