Databases Reference
In-Depth Information
We have also had the opportunity to work closely with members of the Reporting Services product team
at Microsoft to better understand the long-term goals for Reporting Services' features and capabilities.
This has provided insight into the mechanics of the product's components and why they behave as they
do. Without fully understanding the design goals in architecting this product, it's easy for a report designer
to ask questions like Why does it work that way? . . . Why did that do that? Reporting Services has some
limitations that may not make sense to the casual user. I've found that most advanced capabilities I would
like to include in reports can be implemented but not necessarily using my chosen technique. As I've run
up against limitations and have discussed these with the product architects and product managers, the
answers are often in the vein of “that feature wasn't designed to work that way. You can accomplish the
same thing by using this other feature or technique.” My goal is to share these techniques and capabili-
ties with you.
Unlike the previous chapters on report design, I'm not going to do much hand-holding in this chapter.
By now, you should know how to use the features of the report designer and how to change properties,
create queries, and use all of the report items. For each of the report design techniques that follow, I'll
give you enough information to explain the concept and demonstrate the technique, but I won't walk
you through the entire process from start to finish. This will save time and avoid redundancy with mate-
rial covered in the previous chapters.
Reporting Project Requirement Guidelines
Reporting projects are a special breed of software solutions. In the software world, successful projects
don't just happen without deliberate efforts to manage evolving requirements and to steer the creative
effort. Whether you are a corporate application developer, an independent consultant, or the person who
wears all the hats in the department, your project should have a sponsor who defines the requirements
and takes delivery of the finished product. We could spend volumes discussing lessons learned about
failed and successful projects. In short, the secrets of success nearly all come down to effective communi-
cation and the involvement of a customer stakeholder. We've discussed some of these principles and
ideas in previous chapters. This section is a concise set of guidelines that you may consider using to help
you and your project sponsor to cover the essentials.
Key Success Factors
Reporting projects have a much better chance of being successful when the business requirements are
well defined and clearly communicated. In particular:
❑
Report specifications should be documented using a standard format for all reports.
❑
Report designers must understand the source data. In cases where the designer isn't familiar
with the database design and business data, specific queries or stored procedures should be
defined and prepared before report design.
❑
The database schema should be frozen before work begins.
❑
Accurate sample or real data should be available to support the design and testing of all reports.
These may seem like lofty goals. The fact is that oftentimes you may not be able to control all of these
factors. Experience will help you to know where to draw the line between the situations where you
should work with less-than-ideal conditions and situations in which you should put your foot down and
Search WWH ::
Custom Search