Seeking AutoSearch Advice
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
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
This discussion has been closed.
Comments
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
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
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
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
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
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
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
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