Real-world tools #1: ReportBuilder

There are some third-party components I use that I'm still not sure about, but that are so embedded in my work now that the thought of changing them isn't all that appealing. ReportBuilder (RB), by Digital Metaphors, isn't one of those. This, it turns out, is one of the best decisions I ever made. My experience below is based on version 10 Enterprise.

I think I first read about it in the Delphi Informant magazine about eight or nine years ago when an article was written that was a semi-tutorial and review at the same time. One of the nice things for me is that this is all that Digital Metaphors do: a report writer for Delphi. The product has now been around for a long time and during the time that Delphi Informant was running, ReportBuilder won Best Reporting Tool and Best Product of the Year for several years running.

There are a few really good reporting solutions out there, all of which are such a pleasure to use after using QuickReports! I guess a lot of Delphi developers use Rave Reports since it started being bundled with Delphi, but by the time this had happened, I was already ensconced in ReportBuilder.

For a start, it is written fantastically well. If you ever needed convincing that object-oriented code was the way forward but and never looked at the Delphi VCL, you should see ReportBuilder's code. It's simply the most extensible, accessible and flexible code I have ever come across. There isn't a part of the software that you can't change, get to, manhandle or simply read. As each version progresses and they add new features, they actually go back and make the existing features easier to use as well by exposing more properties.

For me, the best example of this is the report query itself (if you're not attaching to a dataset which, of course, you can). Once you have built up your query (using either the standard Query Wizard or Designer, or your own custom Query Wizard or Designer), you can then access the query as an object. And each part of that query is an object too, so you have the Criteria object and the Join object, etc. You can access this at run-time so you can amend the query to suit your needs just before the report runs, or at least see the query that has been generated for you. Simply use the object properties and methods to change the query and the SQL text itself is updated. This is simply genius and so much easier than having to manually trawl through the query text in order to add a table and its join at a later stage.

As I mentioned, any of the wizards or dialogs can be descended from to make your own class, which you then register with RB and use those instead.

And this mechanism is what allows it to communicate with any database class out there. Of course you're given default support for the BDE, text files and "Just-In-Time" data sources, but because they all descend from a base class, you can use any others on the market. I myself wrote ones for Titan Access and Titan SQLAnywhere by Reggatta Systems when we used those components (more on that another day), and I've had some input on the class for ODBCExpress. Once compiled, RB can connect to your third-party database interface and you'll never think about it again.

Similarly, the new email feature in version 10 supports MAPI and Indy 9 and 10 from different classes, but if you use another SMTP facility then a new class can be derived to support it.

Like Delphi, RB comes in different flavours for different prices. Standard is the entry level system which only allows you to write reports; the next step up, Professional, allows you to include the designer within your software to offer a report-writing solution. Enterprise adds RAP capability which I'll come to below, and Server Edition adds web server support for displaying your reports on the web.

RAP was formally introduced I think in about version 6, although it had been available in beta stage for some versions prior to that. Report Application Pascal is basically a mini-Delphi within the report writer, whereby you can add code to events of the report or any of its components - just like a TForm and the components you drop on it. With each new version, the RAP language expands allowing more and more control over the look and data output of your report. This is so powerful that I can't imagine how I ever wrote a report without it. If you use Crystal Reports, it's similar to the formula language used within it. And like Crystal, you can extend it if a method or class you want isn't in it.

This isn't meant to be a sales pitch for Digital Metaphors so I won't go on to list all of its features, but I should commend them for their excellent technical support via the newsgroups. There are groups for the different sections of report writing and often they will contact you directly if you have raised an issue so you can sort it out between you before the newsgroup is given the solution.

No matter what happens, this is one toolset that actually drives which version of Delphi we use, and as ever they are supporting the latest version of Delphi almost as soon as anyone.

Personally, I believe ReportBuilder is about as good as third-party components get. We recently made significant database changes to our main software in order that we could move forward with bigger and better features. This wasn't an easy change, it took almost 6 months to get the software working as it was before the changes, and of course it was going to affect every user-defined report written using our software, over which we have no control (that's the point after all, isn't it?). So how did we get all these user reports to play nicely with the massive database restructure? We wrote a conversion utility that changed the SQL of the reports, using RB's SQLBuilder object. How easy did that make it? Well let's just say that I'd still be manually changing them now if that wasn't available. As it was, we never received a single user report by email to convert; we could see the reports as code, change the code as necessary, and save it back.

That alone was worth the price.