According to research, most complex report development
work can be simplified by performing the data source computation in advance. For
example, find out the clients who bought all products in the given list, and then
present the details of these clients.
In developing such reports, it is the
“computation” part and not the “presentation” part that brings about major
difficulties. In which stage will the computation be most cost-effective? Shall
the computation be set in the data retrieval scripting or the post-retrieval report
presentation?
The report developers as usual are more willing
to compute in the report straightforwardly after retrieving data with SQL or
Wizard. On the one hand, it is because most report tools are capable of some
step-by-step simple computations by themselves, while SQL
only allows for incorporating all logics in one statement and is impossible to
be decomposed into several examinable components; on the other hand, most
report developers are more familiar with the report functions than that of SQL/SP,
and the SQL/SP scripts are more difficult to understand.
However, the report alone cannot give the
satisfactory result. Many report developers find the computational goal is hard
to achieve in the report. They will ultimately be hard-pressed to learn the SQL/SP,
or request the assistance from the database administer. Why?
The root cause is that the report is mainly
developed to present but not to compute. The computation is a non-core feature
of a report designed to solve the commonest and easiest problem. Achieving the
truly complex computational goal will still depend on the professional scripts for
computing like SQL. So, only computing the data source in advance can simplify
and streamline the developing procedure of such reports.
Stuck in a dilemma? On the one hand, the report
can only provide the limited data computing capability; on the other hand, SQL/SP
is hard to comprehend and the computational procedure is neither intuitive, nor
step-by-step. This is such a headache for most report developers.
esProc can solve the dilemma. It is a professional
development tool for report
data source, offering the expected computational capability and the user-friendly
grid style. In addition, it enables the step-by-step computation to present the
result at each step more clearly than report. Compared with SQL, esProc is
easier for report developers to learn and understand. They can use it to solve
the complex computation more easily and independently, including the
computation of the above case.
esProc scripts:
Like SQL, esProc supports the external
parameters. The report can reference the esProc directly through the JDBC
interface.
In addition, esProc is built with the
perfect debugging function, and is also capable of retrieve and operating on
the data from multiple databases, text files, and Excel sheets to implement the
cross-database computation. esProc is the good assistant to reporting tools and
the expert in report data source computation.
No comments:
Post a Comment