Home General
New Blog Posts: Merging Reports - Part 1 and Part 2

Seeking AutoSearch Advice

edited February 2009 in General
Delphi 7 and RB 10.09

We have an application that not only contains a known universe of data
tables and data fields, but which provides users with the functionality to
create their own data entry forms. When the forms are created by the user:

1. We construct the underlying database tables (Links, RI, etc).

2. We populate the rb* tables with the pertinent table(s) / field(s)
information.

3. Integrate the data forms into the user interface.

The AutoSearch Demo examples present cases where the data tables and data
fields are known in advance, which is good for an enterprise solution and
can be easily coded to provide users with AutoSearch capabilities.

As part of our solution, we want to provide our users with a Report Viewer
capability so that they can preview / print reports without launching the
Report Designer. In reality, one department will use the Report Designer to
construct report templates and other departments will use the Report Viewer
application to select report templates and preview / print reports.

With that said, we are seeking advice on a design approach that will allow
us to provide AutoSearch within the Report Viewer application that is
flexible and smart enough to work with Report Templates that have been
created in the Report Designer for an unknown universe of data tables and
data fields.

Has anyone else confronted this engineering problem?

Any help or ideas would be greatly appreciated. If you have ideas,
suggestions, advice and want to take the discussion offline, please contact
me at support@caplencompany.com.

Thanks, Patrick

Comments

  • edited February 2009
    Hi Patrick,

    The most versatile solution would be to create a wizard or dialog that
    leverages the SQLBuilder object and allows your users to visually create
    autosearch criteria on the fields selected.

    It is also possible to load the Query Designer in code however this may be
    more control than you want to give your users.

    http://www.digital-metaphors.com/rbWiki/DADE/Program_Control/How_To...Launch_the_DADE_Query_Designer_in_Code

    --
    Regards,

    Nico Cizik
    Digital Metaphors
    http://www.digital-metaphors.com

    Best Regards,

    Nico Cizik
    Digital Metaphors
    http://www.digital-metaphors.com
  • edited February 2009
    Nico,

    Thanks. I'll explore both options. The short term solution may be to
    expose the QueryDesigner until we think through and develop the Wizard
    approach. With that in mind, how do I hide QD tabs that I don't want the
    users to see?

    Thanks again, Patrick

  • edited February 2009
    Nico,

    I am using the QueryDesignerInCode example to experiment with displaying the
    QD in code. The following procedure is in that example:

    procedure TForm1.FormCreate(Sender: TObject);
    begin

    FSession := TdaBDESession.Create(Self);

    {set SQL properties}
    FSQL := TdaSQL.Create(Self);

    FSQL.Session := FSession;

    FSQL.AllowSelfJoin := True;
    FSQL.DatabaseName := 'DBDEMOS';
    FSQL.DatabaseType := dtParadox;
    FSQL.SQLType := sqBDELocal;
    end;

    I am using the Advantage DB and cannot find any info to place the correct
    values into the DatabaseType and SQLType properties of the FSQL object.

    Do you know what these values are for the Advantage DB?

    Thanks, Patrick

  • edited February 2009

    I read your original post. (Not sure I completely understand what you are
    trying to accomplish.)

    I understand you have one set of users that will 'Design' reports and save
    to .rtm. Another set of users will 'View'.

    The "Designers' of the reports can use the RB Data workspace to design and
    link queries. They can create Search Criteria for the Where clause that are
    designated as AutoSearch. In other words, all the smarts about autosearch
    should be saved as part of the report definition.

    The 'Viewers' of the reports, can then preview the report and specify
    autoseach values.

    If it were me, I would not give the 'Viewers' access to a Query Designer.
    If you want to do that, then give them the Report Designer and they can
    access the Data workspace.

    To use Advantage with the RB Data workspace, please see
    RBuilder\Demos\EndUser Databases\Advantage\ReadMe.doc.



    --
    Nard Moseley
    Digital Metaphors
    www.digital-metaphors.com

    Best regards,

    Nard Moseley
    Digital Metaphors
    www.digital-metaphors.com
  • edited February 2009
    Nard,

    Thanks. Your usage assumptions are correct ... insofar as there are two
    types of users ... 1) those who design the reports, and 2) those who need to
    preview and print the reports.

    With that said, the #2 users will need to be able to set date ranged
    constraints when previewing the reports ... which is what led me down this
    path.

    All of the autosearch examples appear to require a developer (me) code the
    search solution for the popup autosearch dialog to collect the date range
    info ... is that correct? If yes, then that's my disconnect, given that the
    users may have constructed data entry forms that I am not aware of, but that
    need to be included in their report designs and previews.

    I agree on "not letting...". Putting the QD in front of rudimentary users
    could result in disaster.

    Patrick

  • edited February 2009


    No, that is not correct. Re-read my post :)

    You can implement autosearch without writing a single line of code. The
    'Designers' of the reports can do this.

    1. Here is step by step directions for creating autosearch parameters via
    the Query Designer

    http://www.digital-metaphors.com/rbWiki/DADE/Fundamentals/Create_AutoSearch_Parameters


    2. Run RBuilder\Demos\Enduser\Report Explorer - once you run the app, it
    contains about 20 example reports that contain autosearch. No code.

    3. RB 11 introduces even more power and flexibility for AutoSearch:

    - use the Design workspace to create Parameters
    - configure Parameter.AutoSearchSettings
    - configure Parameter.LookupSettings - thus parameters can have a pick list
    of values
    - automatic display of Calendar for Date parameters
    - use the Query Designer to bind search critieria to a parameter - thus
    multiple query's can use the same parameter value
    - manually edit SQL and use :ParamName notatation to bind manually edited
    SQL to a parameter



    --
    Nard Moseley
    Digital Metaphors
    www.digital-metaphors.com

    Best regards,

    Nard Moseley
    Digital Metaphors
    www.digital-metaphors.com
  • edited February 2009
    d'oh! ... now this is making a lot more sense ... thanks.

    We have an application form that lists all the templates from the database
    (rb* files) and from the file system (*.rtm files). When the user selects a
    template, we display the report in a ppViewer component. This is the #2
    user that only gets to preview and print a report (no designer interaction).

    Given that the "smarts" are embedded in the *.rtm, is it possible to
    integrate an auto-search into the above mentioned homegrown preview form?
    ... a Search button on the toolbar that when selected will provide similar
    functionality to the search button on the toolbar within the Report
    Designer?

    Thanks for your help.

    Patrick

This discussion has been closed.