Hi Roxanne!

No need to apologize at all... When you mentioned bluntness, I started looking by a "hey you! Moron!" somewhere in the text ;-)

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.

I looked at this data for so long and so intensely already that my retinal prints are burnt onto it by now ;-)

Even if I denormalized some of it, it wouldn't help me because some of the comboboxes that I need to populate in order to add records to some of the tables still have 700 options (I'll tell you more about this further down). My issue with that was that populating a view that feeds a combo, with 700 rows of data from a server is ALWAYS going to take some time. This is where my questions about the umpteen bizobjs come from.

The view that I posted earlier (on which you're commenting) cannot be denormalized. I have 4 tables and that's where the data has to come from in order to allow the user to review something. I repeat, this is a read-only thing.

What bothers me is that the view isn't all that complex, yet since I have no control over what tags are used, the results will take about 8 seconds to come up in my users' environment, which is definitely not acceptable. (I am 99% sure of the speed difference based on previous comparisons betwen my development environment and the users' and I've seen their faces through some demos I've done where a form took 10 secs to instantiate).

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.

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?

Could you please explain why you say these two?

>Plus too I seen elsewhere you've posted about considering to put some lookup data on the client at startup for optimization... another indicator in my book the data isnt modeled appropriately.

>A lookup-intensive app is bound to need functionality outside of the normalized relation data paradigm, that's just how life is in some environments.

Now back to the 700 rows so you're not in the dark...

I'm migrating this client from an Alpha4 database to vfp. The original database has 4 tables and there's only marginal normalization there.

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.

Thanks for your blunt answer ;-)

Alex