Hi Trent,



Thanks for the explanation and for the new event to handle this kind of situation even though I agree with you that at the end, a view will serve much better and will be more flexible to work with.

Edhy Rijo

OK....let me jump in here. First, there is already a way to do both. The BrowseDialog uses a QueryInfo class that gets passed all the way down to the DAL which in a query class written specifically for this class that is independent of any database on the back end. This is handled in the DbDataSourceItem which interprets the contents of the QueryInfo class and then properly builds the query necessary for the results. I have just made a change that will appear in the next update that fully exposes this property immediately before executing the query. It will be called BeforeSearchExecuted and it will give you the full QueryInfo instance that is to be used immediately before it is actually used. This is easier than using the Tokens that allows you to inject logic into the QueryInfo class through the Searching event.



When you get this update and if you elect to manipulate the QueryInfo class, you will just clear out the Fields collection on the QueryInfo and add in the fields that you want to be returned.



Now that this particular argument has been resolved....here is my opinion. You are better off creating a view anyway. It will be easier and was the reason it was introduced in the first place. Let's quickly discuss why the view or alternate table option was added. We had introduced the tokens within the Searching event that manipulated the QueryInfo class. However, there were still some issues that could not be fully realized until the underlying query was accessible. This was a need that came from our medical software. We had this very need, and we were also in control of the framework and knew that we could expose this QueryInfo class and manipulate it as well. Obviously we determined that the cleanest, fastest, and most scalable option was to create a view that could be injected as the query source which ultimately opens up the world in regards to result sets coming back in a browse dialog.



At any rate, you can do it either way...but I still would go the view route in this case.

The Public Function Search() in the browsedialogwindow uses the bo allfieldslist







So it would seem if that list were exposed in the BO properties on the instance level that would pretty much take care of it and be useful in other areas as well. Present all the fields in a picker - either uncheck to exclude or check the fields to exclude, that sort of thing.



Alternately, a property that is a list of fields that if it is not blank would be used instead of allfieldslist.

Seems like an analogous method to the OverrideSearchTableName/Schema would be nice here, something like OverrideSearchSelectFields.

!!!Warning!!!!

For anybody using the view approach the following steps most be done so it will work properly:



1.- In the BOM you must check "Override Primary Key Specification" in the BO Properties and select your PK field or fields used or when you select a record in the listview it will not have the correct PK value in the ListViewItem.Tag property.



2.- The BD property "ReturnSelectedRecordOnly" should be set to True so the correct record is copied the one in the BO assigned to the BD.



I just spend an hour trying to find out why the selected record in the listview was not being copied to the assigned BO and I just forgot that the view had not PK field assigned in the BOM and this was causing the code in the ListView to failed without error and not finding the correct record.

Edhy Rijo

Yes Charles, this refers to the database Schema not the fields, but I am sure there should be some trick to handle this other than using the view.



I am still waiting for Trent to comment on this one.

Edhy Rijo

okay, on searching further here on the forum I get it - the "schema" refrerred to here is something like "dbo." not the structure of the data that will be returned.



Oh well.



So you can override the table, but that gets us back to using a view.



I'm thinking there is an ER in the works here. Shouldn't be that difficult to allow loinfo to pass in the fieldlist to the filldatatable()

Here's the source that uses it in BrowseDialogWindow

OverrideSearchTableName

OverrideSearchTableSchema



Strataframe:Browse Data properties of the Browse Dialog

Where's Override Schema? Is this an event or property or method?