>>I am even entertaining the notion of downright copying those tables to the local hard-drive upon startup.
>
>When I face that sort of thought, I opt to go back to my data model and do some heavy denormalization... but we've already beaten up on this. Just a personal thing with me, I dont like to copy data down local if I dont have too.

Hi Roxanne!

Well, my client has been working on cleaning up his database and although he's not normalizing it, he's limiting the possible values from which I build the lookup table for the combobox, which is "a good thing".

What do you have against copying some data that will be used for read-only purposes upon app. instantiation? I would think it would speed things up, but probably marginally now that I won't have to bring in 700 rows of data every time a form with this combobox is instantiated.

I also LOOOVE your suggestion about a view on a view. If I'm smart enough to have convinced my wife to marry me, I wonder how I didn't come up with this idea in the first place ;-)

Thanks for your ideas!!!!!!!

Alex


>
>
>>A view on a view hasn't occurred to me. How would that speed things up?
>
>Exactly the same way your original example speeded things up except I'm talking local views instead of raw SQL SELECTs...
>
>>>> If instead I break this single select into THREE:
>>>> 1. Join requests and providers into cursor c1
>>>> 2. Join c1 and case_def into cursor c2
>>>> 3. Join c2 and lawfirms into cursor c3
>
>so what I'm suggesting is 3 local views: lv_provider_requests_src = your cursor c1, lv_provreq_casedef_src = your c2, and lv_comboname = your c3. Now I tend to put the "_src" ("source") suffix on the view name for the underlying views just for clarity.
>
>Now the one hassle with this is man handling "no data on load" and requery() order on these puppies. I've had much luck doing this in the bizobj's prerequeryhook() Where I make sure I requery the underlying views before I requery the combo's rowsource view.
>
>Benefits of this approach over just doing selects into cursor is probably your next question right? Not a whole lot... I like it because it keeps my data handling in the view definition and therefore in the dbc with all my other data structures. For example, a year from now that combo isnt showing the correct list. Where's the first place you look for bad data? In the dbc. Plus too sometimes doing an index on the fly on the underlying source views can help speed things up just a little.
>
>As an afterthought here, a 700+ item combobox is really pushing it IMO. Have you reconsidered your UI design at all for this deal?