| Subject | RE: [IBO] FR vs QR |
|---|---|
| Author | Josipovic, Nikica |
| Post date | 2002-01-13T21:25:13Z |
I'm not Geoff, but also a RB-user :-)
The Report Designer is available to the user without additional work. Just
drop a Designer on the form and there you go.
There is also the Report-Explorer...A complete end-user solution. The user
can browse available reports (stored in the database itself) in a
windows-explorer like interface with folders, subfolders and so on. The user
can create completely new reports, use the report-wizard and can create the
data-access components on the fly (also with wizards or with the hard way).
DADE is the end-user solution for data-access and RAP is a complete
scripting-engine for the end-user. With RAP, the end-user can create
event-handlers, access properties of all components and so on. This is
really a bummer, and although Geoff does not use it I find it invaluable.
My actual App is a completely generic solution, so I have to design all
reports as generic as possible, too. I just use the application itself and
the report-explorer to generate all reports including run-time variables,
event-handlers and so on and publish it to the users by simply committing my
work :-) As all reports are stored in the database, a simple datapump is my
deployment :-)
On thing I love in the end-user solution is the built-in data-dictionary
(does not compare to the one in FR) which can define aliases for tables and
columns for the complete database. Also it stores possible joins of tables.
The end-user can (if set so) only see the tables and columns as defined in
the DD and so groups of users can see only groups of tables (pretty
important for me. I do not want a user to run a report on the overhours of
other users and so on). Also, as the user only see's aliases he will not
know what tables in the DB itself he is querying which does add a nice
secure feeling for the developer...If they now drop two tables as defined in
the DD onto the Data-access-environemnt, RB will automatically create the
join for them. The end-user has no headaches anymore with anything :-)
P.S. Unlike in FR the end-user will never use Data-access components
themselves. Theey define queries with a wizard which are then dropped into
an ER-like diagramm with lines drawn for joins and columns shown in
table-boxes. Much more easy to learn for the End-User.
All in all, FR is by far faster and has a smaller footprint than RB. On the
other hand, RB is much more powerful and funtion complete. The do reporting
for a long time now, and also RB is done by a team of Developers, not by a
single person, and one result of is is the much better Usability. Unlike
most other report-vendors (including, but not only FR) they did understand,
that the end-user in NO developer and they do everything to make the
end-users live more easy. There is a help-file for the end-user designer
which can be deployed freely and also a complete PDF-manual for end-user
reporting only. This and much details in the solution make it the most
end-user friendly solution out there. The price you pay is decreased speed
for large reports, but I can stand this pretty easy as it is not slow, just
not as fast as FR :-)
P.S. Fast Report is actually quite nice. I do not want to bash it at all. It
is fast, it is small and it has lots of features and offers very much for
the really low price. Actually I find it alsmost too cheap for what it
offers. I did the trial and originally I wanted to buy it. But I also did
the RB-trial and decided against FR despite the much higher price. I just
wanted to show that there are other very good solutions, too, and especially
for end-user solutions, FR is probably not the best one.
Hope this helps and CU,
Nick Josipovic
Business Analyst / Market Intelligence
Global Corporate Communications
SAP AG
Neurottstrasse 16
69190 Walldorf
T ++49 6227 762945
F ++49 6227 7834457
E nikica.josipovic@...
http://www.sap.com/germany
The Report Designer is available to the user without additional work. Just
drop a Designer on the form and there you go.
There is also the Report-Explorer...A complete end-user solution. The user
can browse available reports (stored in the database itself) in a
windows-explorer like interface with folders, subfolders and so on. The user
can create completely new reports, use the report-wizard and can create the
data-access components on the fly (also with wizards or with the hard way).
DADE is the end-user solution for data-access and RAP is a complete
scripting-engine for the end-user. With RAP, the end-user can create
event-handlers, access properties of all components and so on. This is
really a bummer, and although Geoff does not use it I find it invaluable.
My actual App is a completely generic solution, so I have to design all
reports as generic as possible, too. I just use the application itself and
the report-explorer to generate all reports including run-time variables,
event-handlers and so on and publish it to the users by simply committing my
work :-) As all reports are stored in the database, a simple datapump is my
deployment :-)
On thing I love in the end-user solution is the built-in data-dictionary
(does not compare to the one in FR) which can define aliases for tables and
columns for the complete database. Also it stores possible joins of tables.
The end-user can (if set so) only see the tables and columns as defined in
the DD and so groups of users can see only groups of tables (pretty
important for me. I do not want a user to run a report on the overhours of
other users and so on). Also, as the user only see's aliases he will not
know what tables in the DB itself he is querying which does add a nice
secure feeling for the developer...If they now drop two tables as defined in
the DD onto the Data-access-environemnt, RB will automatically create the
join for them. The end-user has no headaches anymore with anything :-)
P.S. Unlike in FR the end-user will never use Data-access components
themselves. Theey define queries with a wizard which are then dropped into
an ER-like diagramm with lines drawn for joins and columns shown in
table-boxes. Much more easy to learn for the End-User.
All in all, FR is by far faster and has a smaller footprint than RB. On the
other hand, RB is much more powerful and funtion complete. The do reporting
for a long time now, and also RB is done by a team of Developers, not by a
single person, and one result of is is the much better Usability. Unlike
most other report-vendors (including, but not only FR) they did understand,
that the end-user in NO developer and they do everything to make the
end-users live more easy. There is a help-file for the end-user designer
which can be deployed freely and also a complete PDF-manual for end-user
reporting only. This and much details in the solution make it the most
end-user friendly solution out there. The price you pay is decreased speed
for large reports, but I can stand this pretty easy as it is not slow, just
not as fast as FR :-)
P.S. Fast Report is actually quite nice. I do not want to bash it at all. It
is fast, it is small and it has lots of features and offers very much for
the really low price. Actually I find it alsmost too cheap for what it
offers. I did the trial and originally I wanted to buy it. But I also did
the RB-trial and decided against FR despite the much higher price. I just
wanted to show that there are other very good solutions, too, and especially
for end-user solutions, FR is probably not the best one.
Hope this helps and CU,
Nick Josipovic
Business Analyst / Market Intelligence
Global Corporate Communications
SAP AG
Neurottstrasse 16
69190 Walldorf
T ++49 6227 762945
F ++49 6227 7834457
E nikica.josipovic@...
http://www.sap.com/germany
> -----Original Message-----
> From: lester@... [mailto:lester@...]
> Sent: Sunday, January 13, 2002 9:48 PM
> To: IBObjects@yahoogroups.com
> Subject: Re: [IBO] FR vs QR
>
>
> Geoff
>
> Just for the record, because I have never bothered with RB,
> is the report designer available to the end customer or do
> they have to get a copy of RB.
>
> FastReport, the report designer is a component that you just
> use in your application, rather than needing an external
> package. It does everthing I want so I stopped looking at
> any others <g>.
>