Board index » delphi » Report Printer Pro vs Report Builder

Report Printer Pro vs Report Builder

Could I get some opinions/features of these packages?

-thanks

-Dave

 

Re:Report Printer Pro vs Report Builder


Okay, here goes...

YOUR MILEAGE MAY VARY STATEMENT.  I'm not intimately familiar with
ReportBuilder.  I've seen the trial versions, and I worked on a development
project a few years back which had a couple of reports done in RB (back when
it was still called Piparti) which I had to modify.  On the other hand, I
know ReportPrinter Pro very well.  I've worked with the current version
since it was in beta, and I'm in Nevrona's volunteer support group, Team
ND -- which in some quarters makes my opinion suspect, but which I assure
you is a matter of voting with my feet.

Let's start with ReportPrinter Pro (RPP).
1) The report architecture in ReportPrinter Pro is, to my knowledge, unique:
Reports are page-oriented, rather than band-oriented.  This makes doing many
things which are difficult-to-impossible in conventional report writers a
snap in ReportPrinter Pro.  If you have any possibility of needing to do,
for instance, "reports" consisting of a lot of heterogeneous forms, or
anything other than tabular data presentation, RPP is definitely the way to
go.

2) RPP's support for banded-style reports is highly flexible.  Rather than
being restricted to a fixed pattern of  bands (Report Header Band, Page
Header Band, etc.) you're allowed to lay down any arbitrary pattern of of
iterating (data-linked) and non-iterating (including such things as group
and row headers and footers) bands which suits your purpose and link them
together to get the report structure you need.   There's no "subreport" in
RPP as such -- instead you simply add more iterating bands (or, for more
difficult situations, completely new page layouts to the report).

3) RPP uses an external report definition file which can contain multiple
reports.   Methods of the main report component in Delphi/BCB allow you to
obtain a list of report names and descriptions contained in a definition
file.  This approach greatly enhances the ability to update and even to
adding reports to fielded applications.  On the other hand, for situations
in which you do not want to have to worry about distributing an extra,
albeit small, file, the definition file can be completely compiled into the
executable.

4) The visual report designer in RPP ("RAVE") is a separate executable,
rather than being an elaborate Delphi form designer.  One consequence of
this is that the end-user report designer for RPP is *exactly* the same as
the developer's designer, with the exception of being stuffed into a DLL and
having definition files loaded and saved through the intervention of the
hosting Delphi application, permitting the developer to control the process.

5) RAVE is the best report layout tool I've ever used, no ifs, ands or buts.
My previous standard in this area was the report designer in MS Access, but
RAVE beats if for ease and precision hands down.  And I shudder every time I
have to open up CrystalReports.

6) In line with the decoupling of the report designer from Delphi, RPP's
data architecture is only loosely coupled  to Delphi's.  RPP Reports use a
construct in the visual designer called a "data view", which you can think
of as generic tabular data source.  Report data views are linked to
Delphi/BCB components called "connections".  There are a number of different
types of connections, notably ones which are linked to and consume data from
Delphi TTable and TQuery components.  There are a number of connection
variants for direct use with various popular BDE-alternatives, and there is
a general-purpose TDataset-linked connection which I've found always "good
enough" for a data coming out of a TDataset-descendent-based provider.
Finally, there is a generic "custom connection" which allows you to generate
report data views based on *any* data by coding the events of the
connection.  Since all the other connection components are descendents of
the custom connection and have the same event sets, you can do a lot of
highly useful things by coding the events of specialized connections.  To
give one example, its possible to produce the equivalent of calculated
fields inside an RPP report without needing to set up persistent fields in a
TDataset.

7) The RPP visual report designer has an open architecture which allows you
to create and add to the design environment your own report components.
Doing this requires essentially the same skill set as building Delphi
components -- the visual designer is (surprise, surprise) built in Delphi --
plus a little specialized knowledge about how RPP works, which is provided
by documentation which comes with the product.

8) Another unique feature of RPP reports is "mirroring".  It's difficult to
describe what this is without having the designer in front of one, so that
one can point and grunt, but in essence it allows one to design standard
chunks which can be propagated throughout a report, or across a series of
reports within one definition file.
One example of using mirroring would be to design a standard page header for
a set of reorts.  Future modifications to the header can be made by made by
doing the changes in *one* place, and having the changes propagated through
all the reports by virtue of the mirroring.  Theres's also a variant called
"data mirroring", which allows you to modify arbitrary pieces of a report
based on values of a field in an incoming data set.

9) RPP comes with a set of components for reports not visually designed --
these were in fact the product before the current version (RPP 3).  With
these you can print literally anything you can code.  They'll work for you
when everything else runs out of gas -- although at this point, I find
there's very little I can't do with RAVE-built reports.

10) Nevrona has been widely excorciated for their documentation.  I'm in the
minority (a very, very small minority, apparently) who feel that the
documentation is pretty good on the whole.  It's far better than the
component documentation I have from most of the vendors I do business with,
the notable exception being Turbopower.  The documentation's biggest
problem, IMO, is that the RPP product is so powerful that producing truly
complete documentation is a monumental task.  I've found that between the
demo project and the source code which ship with the product I've been able
to pretty much plug all the holes.

11) Because of its unique architecture, RPP has a relatively difficult
learning curve -- using it well requires a definite mental paradigm shift.

Now, as for ReportBuilder (RB), to the extent I'm able to comment on it:

1)  The product appears to be very solid.  Digital Metaphors has a LOT of
happy customers -- like most everybody who's switched to ReportBuilder after
struggling with QuickReports.

2) RB is a conventional banded report writer.  This is an observation, not a
knock, and many people never feel the need for anything different.  In terms
of structure and design, it's much like QuickReports, with the bugs left
out.  The report designer is much better than QR's, though not, in my
opinion, as good as RPP's.

3) RB reports are inside Delphi, in a way that RPP reports are not.  This
means that it is possible to modify visual components in an RB report
directly with Delphi code, as one could with QuickReports.  A number of
developers I've talked to are put off by the fact that this is *not*
possible in RPP.  (There are ways to modify RPP reports with Delphi code,
but they're more complicated to use and less complete.  RPP has other means
for similar ends, including data mirroring, and including a scripting
language which has been in beta approximately forever -- I haven't missed it
very much.)

4) RB has an indirect data architecture -- something called a data pipeline
which I believe feeds off of data sources -- I believe there are variants
for various types of datasets, and one for non-dataset-derived data.  I
don't understand the architecture or the reasons behind it -- some RB users
need to chip in here .

5) I think that one of the big improvements in the most recent version of RB
is export formats.  I understand one can do things such as sending reports
directly to Excel-format files.  I'm told that this sort of thing is a big
issure for many end users, and certainly it eclipses anything possible in
the current version of RPPro.

6) It's my understanding that a lot of the features I've touted in RPP have
become available in some form in RB (external report files and custom
reporting components,  for instance).  (And probably vice-versa --
competition is a wonderful thing.)

Bottom line -- I use RPP and love it.  If it hadn't been around, I'd have
long ago acquired RB, because I long ago gave up trying to use Quick Reports
for anything with the least bit of complexity about it.  As it is, RPP is
the most powerful report writer I know, and I don't miss having a more
conventional reporting tool around.  Beyond that, the best advice I can give
is to get the trial versions of both products and start playing.  HTH.

Quote
Dave Kauffman <anig...@ameritech.net> wrote in message

news:394a44c8@dnews...
Quote
> Could I get some opinions/features of these packages?

> -thanks

> -Dave

Re:Report Printer Pro vs Report Builder


"L. S. Lichtmann" <condaptr...@earthlink.net> wrote:
<snip>

Quote
>Now, as for ReportBuilder (RB), to the extent I'm able to comment on it:

<snip>

Quote
>4) RB has an indirect data architecture -- something called a data pipeline
>which I believe feeds off of data sources -- I believe there are variants
>for various types of datasets, and one for non-dataset-derived data.  I
>don't understand the architecture or the reasons behind it -- some RB users
>need to chip in here .

   I guess it's just so that RB always connect to a data pipeline.    
   There are BDE,Dataset,Text and fully generic ones.

Quote
>5) I think that one of the big improvements in the most recent version of RB
>is export formats.  I understand one can do things such as sending reports
>directly to Excel-format files.  I'm told that this sort of thing is a big
>issure for many end users, and certainly it eclipses anything possible in
>the current version of RPPro.

   That's TExtradevices from www.waler.com, not RB. In addition to
Excel, there's RTF,PDF,HTML,CSS2,Quattro,Lotus, etc. It's been
available for quite some time. It's really great and I've gotten a lot
of use out of it.

Quote
>6) It's my understanding that a lot of the features I've touted in RPP have
>become available in some form in RB (external report files and custom
>reporting components,  for instance).  (And probably vice-versa --
>competition is a wonderful thing.)

    Yep. I usually read all my reports from a DB. My net-oriented apps
easily update their reports by downloading a small (usually about 30k)
file and just switching the current report DB. You can also use
regular files if you want to.

    There is one feature you don't mention, RAP, which is a
pascal-like language that allow you to do a lot from inside your
reports. The end-users can also write new reports using this, which
may be a major feature if your users can handle it :-). It's only
available on the Enterprise Version (I only have the Pro version).

_________________________________________________________
Luiz Marques                       s...@nospam.stg.com.br
[Remove nospam]
Starglider Systems
_________________________________________________________

Re:Report Printer Pro vs Report Builder


Dave,

Larry explained very well everything in detail. Everything is true, and we
all appreciate such a detailed description and comparison on these two great
reporting tools.

However, there is a support issue. Nevrona used to be very good in
supporting their users. But it looks to me that something strange is
happening there and I don't like it. Before you make a decision, I think
good idea would be to read a little bit their news groups
 nevrona.rppro.rave.general - see my post 'Happy aniversary', and
digital-metaphors.public.reportbuilder.general ).

Few months ago I was in the situation to make a choice for a new reporting
tool, because I got fed up with QR. My choice was ReportBuilder, even thou I
(kinda) liked ReportPrinter better. The only reason was responsivnes of the
company (updates, new releases, and prompt answers to the users)  which I
did not see in Nevrona. It looks like Larry is the main support guy (very
knowledgeable), and he is just a volunteer (not an employee of Nevrona).
Occasionally someone from Nevrona answers some questions (with big delays),
but I think that's not enough.

Try both tools, read both news groups, get a feeling about the company, and
decide.

HTH.

Zoran.

Re:Report Printer Pro vs Report Builder


That is, if you can get to Nevrona's news server. In the last few months
they are having problems almost every week. For example, I was not able to
connect for the last 4 days. (I am lucky that I my project did not depend on
it).

Zoran.

Re:Report Printer Pro vs Report Builder


In article <8iohau$t...@bornews.borland.com>, zzo...@telocity.com
says...

Quote
> That is, if you can get to Nevrona's news server. In the last few months
> they are having problems almost every week. For example, I was not able to
> connect for the last 4 days. (I am lucky that I my project did not depend on
> it).

We moved our newsserver machine to a much faster and more reliable
location but don't have the domain name moved over yet.  If you go out
to our web site, we have details on how to access the newsgroup at the
new server (at IP 208.225.207.130) until the domain name is transferred.  
Unfortunately we are using Register.com and they are taking a few more
days than expected to transfer the registrar before we can transfer the
IP address.

Of course, we would have been able to answer your questions through free
email and telephone tech support if your project depended on it.

Jim Gunkel
Nevrona Designs

Other Threads