Hi Guys,



FWIW we have used this approach to report selection for many years now and it has served us well thus far.



Cheers, Peter

I just now read this and I see where you are coming from.  This would be really convenient to have something like you suggest and would be a big time saver.  It wouldn't have to be very complicated and handle every situation anyway because once ou get beyond a few parameters it becomes too much for the end-users most of the time.

To go a step further, a Query by Form (QBF) feature would be "nice" but I don't know how difficult that would be but I could see where it would benefit all users of SF.

Russ Brown (Using C#2010/SQL Server 2008)

Could you please give us a simple example showing this base class and how do you populate it with different fields of different tables joined?

I agree, Edhy.  Thanks for your input.

Hi Trent,



I understand your position, but what am I asking for is just a common control, easy to setup and subclass like the Browse Dialog to allow us to grab parameters and then do whatever we want with it and I see this kind of control in the Browse Dialog.



I know this will not be enough for every kind of report, but in fact like the Browse Dialog, it will be enough for the majority of simple reports that needs to be created in every application. In my case as a Consultant, I get to build all kind of applications for all kind of budgets and then get to do the same thing over and over again, that is the main reason why I get Frameworks to help me in this process, that is why I like the StrataFrame design and tools, RBS, DDT & Localization Messaging which I use in all my projects, it is just perfect for the kind of work I do everyday.



All applications I do will need some reports, some will be really complicated but the majority will be just standard simple reports which will require from 2 to 4 parameters, some of those will be dates which requires a "From - To" dates and the way the BD allows us, developers to create a filter dialog for forms is very impressive and easy, so I strongly believe the same concept could be apply for reporting instead of me creating the same type of dialog over and over again for every application and per reports.



I know this is not an easy control to build and once it is done if you decide to make it, developers will keep asking for more like I am doing now, but that is the nature of having a framework in the first place, to help us be more productive and to keep asking you guys for more and more

Edhy Rijo

Edhy,

I am not sure how to respond to this post as I pretty much would not use the BrowseDialog for reporting...at all.  The BrowseDialog is intended for working with a single result set.  Though we have added the ability to create joins, etc. through the override properties, this is still not a good mechanism for capturing information prior to a report.

First, you should have a base class in your report environment that is a critera class.  This criteria class is populated with custom properties for each report.  You then have a root "Populate" method that takes this criteria class and executes a stored procedure (or other query) to retrieve all result sets necessary.  In our medical application, we even save off this criteria class by serializing it by user so it remembers the settings use on a per user basis the last time the report was run.

Here is the deal, Edhy.  Though we could create a low-level criteria class like you are suggesting, most reports, especially the bigger the app becomes, really need more sophisticated queries.  So the end-user should just be presented with a dialog to capture the information necessary, then the criteria captured passed over to the report engine.  If you will recall, in class we talked about how to create a criteria and report data source for each report in your application.  The report data source and criteria may actually be used across more than one report, but this gives the most granular level of flexibility.  StrataFlix tries to show this as well, though it doesn't actually save off the criteria, etc.

Also, Edhy, some of our criteria screens are far too complicated to be used in a "boxed" situation like this.  We have some report criteria dialogs that are very complex and something like this could just not be canned.  For simple reports, I see what you are getting at.  But more likely, we should create a reporting criteria capture and management environment similar to our medical application.  But even if we do this, the query portion should still fall on your applications responsibility because report queries become too complex.  Heck, in our medical application when dealing with billing transactions, we could be dealing with millions of records, dozens of different tables, and at times, 10-20 result sets coming back from a SPROC.  So though I see what you are trying to get at, I just don't see how this would be feasible for most environments.

We will sit down and talk about your situation, but ultimately, I think our time would be better spent creating a broader reporting criteria, data source, and criteria capture management tool within the framework (which BTW, is actually already on the list for the future).

All my reports need some sort of parameters, I have been using Browse Dialogs in order to grab those parameters values from the user and get the records, pretty much the same way used in the StrataFlix sample.



This is OK but have some issues:

1.- All the records are shown in the listview before we can show the report, it is somewhat acceptable but not very clear to end user why they need to see all records in a listview when they are trying to see the report.

2.- You can not use JOIN conditions for the query, so we get the parent record, then do another trip to the server to get the rest of the records after closing the Browse Dialog.



I believe that the dynamic functionality existing in the BD to create the search fields and show them to the end user in a nice dialog is just great for us (developers).



We need a Browse Dialog control for reporting with the following functionality:

1.- Same design functionality as the BD without the listview or panel info.

2.- Allow us to access the parameter values entered by the user so we can send those to a stored procedure to get the desired data in one trip.

3.- A collection of Business Object Property which will allow us to use the FillMultipleData from the control and fill all BOs needed.

4.- Any other functionality I may be missing.



I believe that since you know very well the BD control that this kind of control can be easily created based on what you guys have been done already with the BD and leave the BD the way it is now.



Right now I have a report in which I need to allow the user to filter the data and had to create a quick form just to capture this data and manually add the fields needed and code to grab the entered data and pass them as a parameter to the stored procedure, I could not use the BD in this case because of the kind of query used in the stored procedure, a BD for reports would allow me to create my own subclass and manage and maintain this kind of need in a much better way.



Please put into consideration the creation of a Browse Dialog for reporting purpose.



Thanks.

Edhy Rijo

Edhy, I think you get what I am talking about.  The first principle is to decouple business layer functionality from interface.  A query parser object that looks at "search fields", builds a query, ignoring params not used and knowing what to do with dates and having a method where you can fiddle the results of the process would be very useful. 

i.e. object has a collection of params with properties that determine if the param should be excluded if null or empty and how it should be used in the where clause if not in a default fashion

a property that determines what bizobj this parser is designed for

drop this object onto the form, set its bizobj property and identify the params in the collection.

At run time, set the values of the params and pass the object to the bizobj's fill.   Each time it is used you could use a different combo of params.  Now you can get the values from user interface or other stuff going on in the app and apply them as appropriate to query data dynamically.

Could be used with the getdata methods if you want a cursor that is the not main bizobj etc. Use for reporting, use for pretty much anything.  Flexible queries form a powerful onthefly parser and not dependant on interface constraints.  Params could be filled from scalar calls or whatever.

Seems like the plumbing is already there or the Browse Dialog wouldn't work so well.  Maybe after Texas when I know how to look at SF source better I'll be able to explain more clearly what I have in mind.

(this is a framework design issue we banged around a lot in FoxExpress and when we got it nailed it became one of the most versitle and popular parts of the product)

Hi Trent,

Just for the record, I second Greg's request.  I see a lot of places where this functionality will work for my projects.  Also I am thinking about reporting, the Browser Dialog would make it a great Query tool for reporting, where the end user will use a familiar interface to enter the parameter info and then preview/print the report.  I don't know how is this addressed in SF since I have not done any report yet, but would imagine using the Dialog Browser just for that.

I would be amazed if you surprise us with a beta code to test during the class

Edhy Rijo

Well, some of this can be done and other bits can't.  If you look at the overloads for a FillDataTable, you will see that it accepts a QueryInfo object as well.  This was implements and put in place specifically for the BrowseDialog to create queries without being tied to a specific database type (i.e. SQL Server, Oracle, etc.).  So you could create queries this way if you wanted to.  If you just want to use the BrowseDialog instead and use the SearchFields, etc. then at present, the dialog will have to be displayed (as that was it's intent and purpose).  You can already force the query to execute without user intervention.  But the user would still have to select a record at the moment.  We may consider adding the ability to just execute and return the results regardless of what happens, but there is a lot of other logic that this could impact (all post "OK" logic currently expects that there were results).  This is the first request for this that I have heard of or recall as the purpose of a browse is for a user to make a selection, not just perform a query and hope something comes back, so that is how it was designed and implemented.  So this is something that we would have to inspect to see what would be involved to make this a feasible request.  We can discuss this more when you come to class as well.