So, I finally bit the bullet and purchased a Delphi upgrade, to D2009. The offer was too tempting and I have started to become frustrated with being left too far behind with Delphi 6.
Thanks to one of the distributors in the UK, Grey Matter, we got the D2009 upgrade for 20% off. This was a promotion they were running for those who didn't want to take advantage of June's "Buy Delphi and get RAD Studio free" promotion. Apart from a slight, but only curious interest in Delphi Prism, there wasn't enough to tempt me, in these economic times, to not take the 20% off instead.
And so I will chronicle my journey to take our 10 year old product, written in Delphi 5 then Delphi 6, to Delphi 2009. The challenges I forsee are more to do with API headers written for some of the hardware devices (clocking terminals) that we support with our T&A product, but time will tell.
To start with, it will be a case of getting the main part of the software converted and see how that goes. I have the latest versions of all our third-party products such as Raize Components 5, TMS Component Pack, ReportBuilder Server & Enterprise 11 and TsiLang Translation.
Could have some fun with older components like the Crystal Reports VCL component for Delphi (for Crystal Reports 7). Anyone got any experience with that?
Should be "interesting"...!
Showing posts with label crystal report. Show all posts
Showing posts with label crystal report. Show all posts
Tuesday, 23 June 2009
Thursday, 21 June 2007
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.
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.
Wednesday, 20 June 2007
Tools of the real world
I should explain what it is I do with Delphi every day, which will maybe give a background as to why I've become what I consider a conservative developer. Conservative, that is, in terms of what software we use. The company I have worked for for the past 9 years develops three main products (payroll, HR and Time & Attendance, combined as a suite), written for Windows using Delphi.
Although we sell that product, maintain it and enhance it, we also write a lot of bespoke plug-ins and utilities to complement it, for the particular organisation that it is going into.
Given that very simple overview, I'll go on in coming posts to what third-party tools we are using, why we selected them, and maybe why we are still using them even though there might be a better or more up to date alternative.
I think the key point to make is that this is real life. This isn't the ideal world of (the fantastic) Coding Horror, these are real-world, business-oriented decisions that are made because we are under tremendous pressure to deliver, we have a 9 year old project and literally dozens of plug-ins and utilities that rely on consistency throughout.
It also doesn't help that this was only my second job which I started at the age of 23. It turns out I didn't know it all then like I thought I did, and God knows I don't know it all now. So there are some mistakes of youth that are still embedded in the product that occassionally we have to work around. The company have been very good in the past in allowing me an extra month or so to refactor some of the big ones out, even though the end result to the user is no change. Which in the long run is time well spent because future work can then be written a lot faster, neater and cleverer.
It may come as a shock now to learn that, as a base product, we are still using Delphi 6. I will come to why at another time, but it may explain why we're using some of the third-party component sets that we are. I will go through each of these individually over the coming posts, exalting them, damning them or just saying why on earth we're using that one instead of another one. They are:
Although we sell that product, maintain it and enhance it, we also write a lot of bespoke plug-ins and utilities to complement it, for the particular organisation that it is going into.
Given that very simple overview, I'll go on in coming posts to what third-party tools we are using, why we selected them, and maybe why we are still using them even though there might be a better or more up to date alternative.
I think the key point to make is that this is real life. This isn't the ideal world of (the fantastic) Coding Horror, these are real-world, business-oriented decisions that are made because we are under tremendous pressure to deliver, we have a 9 year old project and literally dozens of plug-ins and utilities that rely on consistency throughout.
It also doesn't help that this was only my second job which I started at the age of 23. It turns out I didn't know it all then like I thought I did, and God knows I don't know it all now. So there are some mistakes of youth that are still embedded in the product that occassionally we have to work around. The company have been very good in the past in allowing me an extra month or so to refactor some of the big ones out, even though the end result to the user is no change. Which in the long run is time well spent because future work can then be written a lot faster, neater and cleverer.
It may come as a shock now to learn that, as a base product, we are still using Delphi 6. I will come to why at another time, but it may explain why we're using some of the third-party component sets that we are. I will go through each of these individually over the coming posts, exalting them, damning them or just saying why on earth we're using that one instead of another one. They are:
- ReportBuilder 10 (Digital Metaphors)
- ODBCExpress (Korbitec)
- TMS Component Pack (TMS Software)
- IP*Works! SSL (/n Software)
- Indy 9 (Nevrona)
- JEDI VCL
- Crystal Reports VCL
Subscribe to:
Posts (Atom)