>>Dear, I have tags comming out of my ears. Could it be that some of these tables have an average of 60,000 records and one of them 160,000?
>
>only if your not optimized properly. humor me... show me the SQL for the view that seems to take the longest, plus give me the index tags & expressions for each table joined.

Hi oRox!

Thanks for the offer. Actually, it turns out that my bizobjs were working acceptably fast. Jim Weil and I spent saturday afternoon taking apart the form that's taking long to come up and we couldn't find the problem, so I'm recreating that from scratch, which isn't too bad - that was one of the first forms I created with the framework and a lot of the logic was sitting on the UI tier instead of the bizobj.

As far as delayed instantiation of bizobjs is concerned, I found a situation in which this COULD be required and did figure a way to do it:

When the users add a new record to the requests table, a lot of validation has to occurr (duplicate request, request placed by another client, and a few more). All this validation requires opening 3 more views.

However, when the user is just looking at a request and updates it, none of that validation is necessary.

Therefore I created a requests_bo that deals only with the requests table (or view if you prefer). The requests_bo.validate() method checks to see if vartype(this.ovalidate_bo) = "O". If it's not, then it instantiates the validate_bo and asks it to do the validation for us.

This means that I managed to get at least part of my bizobj to instantiate on demand.

Thanks for your help Rox!

Alex