TppReport.AutoSearchFields does not include the field when a parameter is attached

edited February 2010 in General

Before showing a report I parse the AutoSearchFields.
When an autosearchfield is connected to a parameter it's not included in the
AutoSearchFields list.

I don't know since when this is the case.

Using RB11.06b, D2007

Jeroen R?ttink


  • edited February 2010
    Correction. Using RB11.07b, D2007

  • edited February 2010

    Parameters that have AutoSearchSettings.Enabled create associated
    AutoSearchFields at the time Report.Print is called.
    This happens prior to any events firing. If you want to iterate over the
    AutoSearchFields, use the Report.OnInitializeParameters event. I recommend
    tracing the code in TppReport.Print to see how exactly things work. If you
    prefer to process the Parameters prior to calling Report.Print, then
    interate over the Report.Paramters[ ] array.

    RB 11 introduced the Parameters.AutoSearchSettings feature and the timing of
    when the associated AutoSearchFields are created has not changed.

    Nard Moseley
    Digital Metaphors

    Best regards,

    Nard Moseley
    Digital Metaphors
  • edited February 2010
    Hi Nard,

    Never knew I could create only a parameter to change the generated sql.

    I always create a parameter AND an autosearchfield. Using the Query Designer
    I connect the autosearchfield to the parameter and everything works.
    If I only create a parameter and set autosearchfield.enabled = true, The
    Query Designer doesn't reflect this. Eg no autosearchfield is created (like
    you said and like reflected in the TppReports.AutoSearchFields array)
    If I on the other hand create an autosearchfield in the Query Designer and
    connect a parameter to it, the generated sql reflect this, but the
    TppReports.AutoSearchFields array doesn't contain the criteria...

    Here is some inconsistence going on:

    Create a parameter named ppParam1. Make it an autosearchfield with
    fieldalias 'somefield1'
    Open the Query Designer add an autosearchfield 'somefield2' and connect it
    to parameter ppParam1.
    If I look at the generated sql 'somefield2' is used in the where clause but
    are you telling me that
    the executed sql contains, based on the parameter, 'somefield1' as well?

    Kind regards,

  • edited February 2010

    Prior to RB 11...

    The Query Designer can be used to define SQL Search Criteria. You can
    designate a Search Criteria item as AutoSearch. In this case, the Search
    Criteria will create an associated AutoSearchField.

    It is also possible to create AutoSearchFields that are not related to
    Search Criteria at all. For example, if you are not using the ReportBuilder
    Data workspace to build queries.

    The above functionality has been in place for many versions. But it has many
    weaknesses. The AutoSearchFields are not persistent. There is not way to
    associate multiple queries with the same AutoSearchField. There is no
    support for defining lookups. There is no design-time configuration support.
    There is no relationship to Report.Parameters. I am sure I am forgetting
    many other limitations.

    Starting with RB 11...

    You can define Report Parameters that have AutoSearchSettings. When
    AutoSearchSettings are enabled then an associated AutoSearchField is created
    when Report.Print is called.

    The Query Designer can be used to bind a SQL Search Criteria item to a
    Parameter. And there is support for binding many Search Criteria to a single
    Parameter. The first Search Criteria that is bound to the Parameter, will
    update the Parameter.FieldAlias value. You can override this as you like.
    The Parameter.FieldAlias value is used for display in the autosearch dialog.

    When SQL Search Criteria are bound to a Parameter, then the Parameter value
    will be used in the SQL statement at run-time. This occurs whether the
    Parameter has AutoSearchSettings enable or not.

    You can define and configure Parameters at design-time.

    You can define lookups.

    For backwards compatibility, you can still do everything as in prior

    Hope this clarifies things for you.

    Nard Moseley
    Digital Metaphors

    Best regards,

    Nard Moseley
    Digital Metaphors
This discussion has been closed.