organizing reports with delphi and advantage

rbuser

{ // Setup
IDE : Delphi 6 Update Pack 2
DBMS : Advantage 7.0 Local and C/S Setup
}

I am looking for a reporting tool to replace Quickreports.
(The bugs are finally driving me nuts.) ReportBuilder is
my current first choice, but I have yet to fulfill all
the requirements for a proof of concept. There is one
remaining issue that is holding me back.

How do I organize a large number of reports in my
delphi application?

I have perhaps 2 dozen reports in my main application
using Quickreports. 90% are run from a reports screen
with Preview and Print options, and I just create
the report dynamically, run it, and release it.

iPrinter := FormMain.GetPrinterIndex(0);
if iPrinter > -1 then begin
RItemsSold := TReportItemsSold.Create(nil);
RItemsSold.PrinterSettings.PrinterIndex := iPrinter;
RItemsSold.ReportTitle := 'Items Sold Summary';
RItemsSold.ReportFilter := F.sFilterString;
RItemsSold.Prepare;
if Preview then
RItemsSold.PreviewModal
else
RItemsSold.Print;
RItemsSold.FreeOnRelease;
end;

The other 2-3 reports are also created dynamically, but run from
different places.

I understand that ReportBuilder has two ways to store
reports in Delphi.

1) Setting up the database scheme in the data tab and storing
the entire report template as a file (or in a database).
I haven't successfully gotten this to work yet. I use Advantage
for my database and I did get the AdsConnection to show as a database
in ReportBuilder, but it is now asking for the Alias. I am using direct
connect strings, and I do not want to code the alias to
my database into the reporting module. Also, doesn't this prevent
my from reporting on filtered records or records assembled using
sql string generated in my application? I understand that I could
only report on tables or queries as is in the Advantage dictionary
or on queries setup in ReportBuilder.

2) The second technique involves dropping a database pipeline on a form
somewhere to connect to a report module. If I use this approach,
then is appears that any event code that I write is stored in that form.
I definately want to be able to code custom events, but how do I
organize 24 reports this way? Does each report need its own form?
What do I do with all these forms? This seems like a maintanence
nightmare, and so I suspect that I must be missing something.

I have been reading Report Builder documentation and trying tutorials
for 4 hours, and I need a boost over this hurdle. I am really hoping
I can make ReportBuilder work.

Here is my current wish list :

- A tool that works well with Advantage (at least as well as QReports)

- Able to custom code events using Delphi tools and methods.
I want to be able to easily access MainForm.SomeRoutine in the
report to drop a value on a report.

- Able to store and reuse multiple report templates with multiple
database layouts. So the orders report, for instance, could be
used to list orders from a date query, or orders by a customer,
as long as the field selection list was identical in the query.
Only the from and where clause of the SQL would be different.

- Great variable and total flexibility like I have seen in
ReportBuilder so far.

- Excellent visual report designer.

- Abililty to have multiple subreports that are unrelated.
So have a list of orders based on one query, then in the same
report, have a list of customers that fulfill some possibly]
unrelated criteria.

- Able to stretch controls more intelligently. Especially
stretching controls together on the same band.

Any help would be appreciated.
Thanks,
Scott Lynn

nicocizik

Hi Scott,

Thank you for evaluating ReportBuilder!

1. Looking at our Advantage Database plugin, it was severely out of date.
This morning I sat down with another engineer and updated the plugin to
support the use of the ConnectionPath property rather than just the
AliasName. This should also allow you to use the Advantage datadictionary
as well if you need. There is now a patch available with these changes. If
you are interested, please send a email to support@digital-metaphors.com
requesting the patch and we'll get it out to you ASAP.

2. Instead of placing 24 reports on individual forms, you could save each
report to a template file and load/print them dynamically from a single
report component on a single form. This would essentially work the same way
our end-user solution works except you would be loading report templates
from your hard drive rather than from a database. To dynamically load a
template from file you will need to code something like the following:

Report.Template.FileName := 'MyReport1.rtm';
Report.Template.LoadFromFile;
Report.Print;

3. Looking at your wish list, it seems ReportBuilder will be able to
accommodate most of your needs. Let me know if you are having trouble
accomplishing a specific goal and we'll work to fix it for you.

--

rbuser

Thanks,

The plugin looks great so far.
Thanks for your help and the great turnaround.

I understand your suggestion concerning the 24 reports using template
files. Is the database schema information from the data tab also
stored in the template?

Also, what about any event code that I add to the report.
For instance, if I wanted to combine fields in an expression:

procedure TFormMain.ppStupidVariableCalc(Sender: TObject; var Value:
Variant);
var
sLast, sFirst : string;
begin
sLast := Trim(tbLargeTestLastname.AsString);
sFirst := Trim(tbLargeTestFirstName.AsString);
if (sLast = '') or (sFirst = '') then
Value := sLast + sFirst
else
Value := sLast + ', ' + sFirst;
end;

I cannot see how these are stored in the template files.
These events are currently stored in the form where I
drop the report component. So I am still left trying to
understand how to organize reports with Delphi events
attached.

Specifically, if I have 10 reports, each with custom
events coded in Delphi, how do I organize them? I hope
they don't all go in the same delphi file where I have
to name variables and components to avoid duplication.

Your help is appreciated.
Scott Lynn

In article <3faa7031$1@dm500.>, "Nico Cizik \(Digital Metaphors\)"

nicocizik

Hi Scott,

Yes, the database information from the data tab (or DADE) is saved down in
the report template.

When creating a template, the actual names of the delphi events that apply
to a report are saved down. This is a little risky due to the fact that the
event handler names or code might change for each template. A solution to
this problem would be to use RAP. Report Application Pascal (RAP) is
ReportBuidler's run-time Pascal development environment. RAP enables the
entire report definition (Data, Calculations, and Layout) to be stored
outside of the application executable. Using RAP, developers and end-users
can code calculations and event-handlers without Delphi. RAP is also
extensible meaning you can easily register their own built-in functions and
objects to meet specific requirements.

RAP is only available with the Enterprise edition of ReportBuilder.

--