okay, again I may not be thinking this throug, but my idea is to use two BOs, one for the BD and the one that will be filled from the result of the BD. On looking at the BD properties I guess the problem is that the BD will let you specify the BO but not the designate what fill method will be used ? ( seems a good ER that that be added to BD props to let you point to a BO Fill method or sproc )



And I take it that Override Schema won't have anything to do with this either ?

Wow!!! either I did explain myself correctly or you are mind reader Greg



Thanks for the clarification you are right on the spot.



Of course by using the view and my approached and then will need to modify all the forms logic in which this BD is being used, not a big deal, but I would have preffered not to do so, but at the end, those forms will also benefit of having the denormalized fields instead of the nice Custom Fields Properties which I felt in love with when learning SF.

Edhy Rijo

Actually, one of the very cool things about BOs is that you can fill a BO will any data. It does not have to even be related to the table/view that was used to map the BO. Of course, things can get weird if you aren't careful when doing this. I use this in a few ways. I have fill methods that will fill the BO just for combo or list filling, filling only data actually needed in the list (name and ID sort of thing). I use it to fill BOs with denormalized data (i.e. load the name of FK record). Many times I'll create custom field properties to access these other columns. The trick is to understand that if you don't fill in a column that the BO is mapped to, if you access that column, you'll get an error.



The issue Edhy was having was that it appears that we don't have control over what is put into the select statement when using the BrowseDialog. Thus, if you have a table that includes some monster fields, the search can be slow. He's concluded that using a view is the way to go, so he can exclude those large fields and also include some denormalized fields. He then uses normal fill methods when he wants to populate the form with the result of the search (I think that's what's going on anyway).

Hi Charles,



Yes you are right, but in the BD I don't see how this could be done since the SELECT statement is done somewhere internally in which I don't see how we could hook up.



I have used your trick several times specially when exporting to Excel and in fact the BO is very flexible allowing us to manipulate its datatable, but again I cannot find how this could be done from a BD.

Edhy Rijo

( I'm posting this without thinking it through completely so bear with me if it turns out to be complete nonsense )



For some reason I assumed that if the fill method of a BO did not return all the columns it would generate an error. This doesn't seem to be the case. I just dropped a bo on a form that has a number of Varchar fields etc and in the parentformloading just did a filldatatable to get four columns, excluding varchar, varbinary etc. and I got a cursor.



Couldn't you to that for the BD and then use a different instance of the BO with a full column fill method to get a single chosen record with fillbyprimarykey (or for that matter a set of records)

Ok here my conclusion, a view should be used and in this case of refactoring the source BO for the Browse Dialog it was worthy because in the BrowseResultLayout I need to show some calculated fields which I created using Custom Field Properties and those where also slowing things down a bit, so I decided to create my BrowserDialog view with a JOIN condition to get the calculated fields in a single trip and now getting and showing the data in the Browse Dialog is much faster and responsive.



One caveat to take into consideration using this approach is that after the user selects the record to work with from the BD, I them have to search that PK in the primary BO used in the form which in this case is not the one used in the BD. I know this can be confusing sometimes but in my case it works just fine because searching a record using the BO.FillByPrimaryKey(PKValue) is much faster than looking for many records in the BD which will include those VarBinary or Varchar fields that are not used in the BD.



Hey Alex, hope all this makes sense and if not, please let us know.

Edhy Rijo

Thanks Greg for the confirmation.



I am going with the View route and will do some testing soon, just that I need to do several changes since I want this to be used in all BDs.

Edhy Rijo

I'm not seeing anything either Edhy that would allow the fields included in the select to be manipulated.

I looked at the Searching event, but it does handle the "WHERE" not the fields included or excluded from the BO.

Edhy Rijo

Aren't there some events you can use to manipulate the SQL being sent?