Re: Implementation Scenarios
Greetings fellow programmers,
My company is in the process of converting from QuickReport (QR) to
ReportBuilder (RB). All of the current reports (QR) are formed based reports
within our application.exe. Everytime we would like to update a report (1
report or more) we have to update the application.exe. With the execellent
reporting system of RB, we should be able to get away from that ugly
scenario! There are several ways to accomplish this task from what have been
reading from the support groups/newsgroups. Here they are.
1. Store all the reports in a datamodule and call the reports from a single
dynamic form which would handle all the reports. With this method, I fear
that exe would have to be updated on every change. We're trying to get away
from that scenario.
2. Store all the reports in a package(.bpl / .dll) and call the report from
the application.exe. This is a cool idea. If I understand everything
correctly, we just just have to update the package for every report change.
Fairly simple procedure that way I presume.
3. Store all the reports in a database with the cool tables that Digital
metaphors provided for us. We have implemented this flavor of RB in the
development environment and it works fairly well for us saavy computer
gurus. I think that this might be somewhat cumbersome updating reports in
the database.
What I am asking from ya'all is:
1. What would be the best scenario out of the three to maintain?
2. Hypothetically, what would be the ideal implementation scenario from
begining to end?
Thanks for you time advance!
Regards,
Tim Armstrong
My company is in the process of converting from QuickReport (QR) to
ReportBuilder (RB). All of the current reports (QR) are formed based reports
within our application.exe. Everytime we would like to update a report (1
report or more) we have to update the application.exe. With the execellent
reporting system of RB, we should be able to get away from that ugly
scenario! There are several ways to accomplish this task from what have been
reading from the support groups/newsgroups. Here they are.
1. Store all the reports in a datamodule and call the reports from a single
dynamic form which would handle all the reports. With this method, I fear
that exe would have to be updated on every change. We're trying to get away
from that scenario.
2. Store all the reports in a package(.bpl / .dll) and call the report from
the application.exe. This is a cool idea. If I understand everything
correctly, we just just have to update the package for every report change.
Fairly simple procedure that way I presume.
3. Store all the reports in a database with the cool tables that Digital
metaphors provided for us. We have implemented this flavor of RB in the
development environment and it works fairly well for us saavy computer
gurus. I think that this might be somewhat cumbersome updating reports in
the database.
What I am asking from ya'all is:
1. What would be the best scenario out of the three to maintain?
2. Hypothetically, what would be the ideal implementation scenario from
begining to end?
Thanks for you time advance!
Regards,
Tim Armstrong
This discussion has been closed.
Comments
shown in our End User examples with the Report Explorer. Then when you want
to update the user's database, simply send them a report template file (rtm)
you create. Then your user can open this from file and save it to the
database using the report explorer. The reason this is good, is because if
you give the user the ability to use the report explorer, they can
rename/copy any report or folder, so you won't be able to be 100% sure you
can update the report template programatically, since the user can modify
any report an folder on their database with the report explorer.
What about code? Use RAP. Report Application Pascal allows you to code your
event handlers in the report template so that you don't have to recompile
the app when the calculations need to be changed. Just give your user a new
template. What if you distribute a report, with RAP code and realized after
deployment that there was a bug in your event handler that you need to
change? Sure, you might be able to have your user edit the RAP code, but you
did not give the user the ability to change the RAP code because raIDE is
not in your uses clause. Another catch is that the user has spent time
editing the report to their liking, but need the RAP code changed? RB can
handle this. The user can send the template to you to edit the RAP code, or
you can send them a small utility exe that can load the template and modify
the RAP code in code and change it. Here is an example of modifying RAP code
in an existing template in code:
http://www.digital-metaphors.com/tips/MoveGroupHeaderBeforePrint.zip
Use DADE for data access, where the queries are stored in the report
definition just like RAP is stored. You can load RB datamodules to a report
and save datamodules to the database or file just like a report template.
See the Data tab's File menu for the import, export and merge options. You
can use the Data Dictionary component to easily allow you users to see which
tables and help them with joins and linking by using the AutoJoin feature
which automatically joins and links tables as they use the query tools to
design queries.
From beginning to end, use report templates on a database. Manage them with
the Report Explorer. Use RAP for calculations. Use DADE for data access. See
our end user database examples if you have any questions. In order to
control the end user environment, you usually just have to add or subtract
from the uses clause. See the article in the Tech Tips newsgroup on
Controlling the End User Environment.
Cheers,
Jim Bennett
Digital Metaphors
http://www.digital-metaphors.com
info@digital-metaphors.com
a very successful release of Report Builder in the very near future.
Once again, Thank you.
Best Regards,
Tim Armstrong