Hi Edhy.

Hi Ivan,
Thanks for the explanation and sample code.  After analyzing the situation with my colleague, we came to the conclusion on using your kind of logic, primarily because we want to be able to add new reports and have the lowest impact while delivering the report to production, using a BO with a dummy table or view would require us to update the database and have users logged out to accomplish that.

We are re-created this project from the original Visual FoxPro application and there are a gazillion filter conditions and more could be added with the new revision of the application in SF.  There are already around 70 users between 12 offices with a VPN connection working on the VFP application so we need to find the right balance to be able to release new reports or conditions with the lowest downtime possible.

Thanks again.

Edhy Rijo

Hi guys.

Hi Larry,
Thanks for the information. 
I like the idea of a dummy table in the DDT specially for maintenance.

Edhy Rijo

Hi Edhy,

I'm using a similar approach to capture parameters for a complex search form. Only instead of a view I created a dummy table in the DDT that I map to. This allows me to bind to the fields on the form and use business rules to validate the search criteria. In the object's BeforeSave event I clear the object and cancel the save to prevent it from being saved. Works great and is easy to maintain.

-Larry

Hi Ben, Trent and all.
I am working on a form that will be use to capture the parameter values to generate a query for reports.  In this case we are talking about multiple parameters, at least 20 or more.  These parameters will be capture in all type of controls, like Textboxes, comboboxes, checkboxes, etc.

My questions is what would be the best way to bind those parameter controls so it will be easier to maintain and also to access their values and enforce testing rules?

Since SF binding requires a business object, I was thinking on creating a  SQL view with all the fields I would use as a parameters and then create a business object and maintain it with the BOM as normally done, but then to be able to capture any parameters value in the form, I would need to add a record to that BO and then make sure it is discarded bo.Clear() or something like that, to avoid trying to commit anything back to the database.

Is there any better approach to this?

Main goal is to make this form easier to maintain when adding more parameters as needed, and avoid having to create a whole bunch of custom field properties and manually link or bind them to the controls value.

As always, any input, suggestion is greatly appreciated.

Edhy Rijo