Databases Reference
In-Depth Information
box was installed with a SQL Server database and an application that would replicate production and
inventory data from the existing database systems. Management within the parent company believed
that they didn't have a handle on the rates of material consumption and product quality. They wanted a
reporting system that would give them the figures they needed to make adjustments to their ordering
and pulp production processes.
Over time, orders would be placed for certain grades of pulp. The system would calculate quantities of
ingredients needed to produce a batch — typically to fill an order for a customer. The order would be
sent to the production floor, where workers had newly installed controls used to ensure the accurate
delivery of pulp ingredients. Different batches of product continued to be produced with varying degrees
of quality, and management's ability to track the consumption of these materials didn't significantly
improve. Management continued to invest in reporting solutions. They bought and developed software
to look for trends and perform statistical analysis but to no avail.
After several months and hundreds of thousands of dollars invested, the product quality didn't really
improve much. Finally, one of the IT managers put on a hard hat and walked down to the production
floor to observe the process. What he learned was a simple lesson: When the orders arrived on their
computer workstations, workers were printing the orders and then putting them aside. They had over-
ridden the automated controls and were using the same manual techniques to make paper that earlier
generations had been using for decades. It was a matter of tradition and pride, and they weren't about to
let some computer do their job for them.
The initial reporting solution was elegant and technically capable. The calculations were accurate and
the report presentation was appropriate. However, the solution didn't fully support the process. This
cultural hurdle was eventually overcome (workers were instructed to use the automated systems if they
wanted to keep their jobs), and the product and process improved. A report is only as good as the data it
presents, and the data is only as good as the information used for collection. The information is only as
good as the process that it represents.
Challenges of Existing Reporting Solutions
For over 10 years, Microsoft offered only one product with substantial reporting capabilities. Designed to
run as a single-user or a small workgroup desktop application, Microsoft Access is a capable database and
reporting solution. In Access 2000, Access Data Projects were added. This extension of the product works
well against a SQL Server back end in a LAN environment. In Visual Studio 6, an integrated reporting tool
was offered for Visual Basic 6, but its capabilities were meager at best. Developers at that time thought this
was a glimpse of things to come in subsequent versions of Visual Studio.
Due to the lack of a unified, consistent approach for reporting, many developers have had to revert to
creating their own custom solutions. One case in point is the reports starter kit project available on the
ASP.NET development support site (
www.asp.net
). The developers did a bang-up job creating a web-
based reporting solution using ASP.NET datagrids and datalist controls. They even made their own pie
charts using line-drawing objects. This effectively proves that .NET is a powerful arsenal of program-
ming tools. However, it also makes the point that we have lacked a strong reporting platform to round
out Microsoft's front-line development and database suite.
When Visual Studio .NET was released in 2002, I was a little disappointed because the only integrated
reporting component was a limited-use version of
Crystal Reports
. Now, before I get myself into too
Search WWH ::
Custom Search