Hi all,



Is it possible to specified or exclude the fields to be included in a BrowseDialog?



Since a Browse Dialog is assigned to a BO I believe that it will bring all fields in the BO, how to exclude a couple of fields in the SELECT statement so only the ones needed are used in the SELECT Field1, Field2, Field3, etc.?

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.

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