M
MattC
Hi,
I am developing a timesheet system that collects information about employees
activities. In this I collect details about projects they do work for, what
type of work, how long, when etc etc.
For distributed data input/storage and display I am happy using ASP.NET.
However ther eis one aspect of the project I am not entirely comfortable
with, report production. The requirement is to produce 6 or 7 reports that
view certain aspects of the data in particular layouts with certain totals,
averages, etc. Getting the data was not to difficult although the ROLLUP
and CUBE function in SQL Server did tend to have a habit of producing more
results rows than I needed.
I wont begin to mention my woes at creating my own version of the Access
TRANSFORM/PIVOT functions.
So in my BLL I began stripping rows and creating new tables to pass on to my
Presentation layer. However once here I found my self having to perform all
sorts of webcontrol acrobatics to get my data to display how I want it. A
combinational mixture of nested repeaters/datagrid/datalists aloong with
many datarelations to link results sets from several complex sql statements,
then there was the color fomatting, in comes the use of the ItemDatabound
event to check rows as they are added.
By then end I have several reports that while look good, have completely
destroyed any sense of object modelling in that area of the code, I
specialised where I could but the difference in data returned made it near
impossible to find any common means to create a useful hierarchy.
So my question after all this is: Is ASP.NET suited to producing/displaying
reports of a complex nature in a way that can be easily maintained? Would
something like Crystal reports be better used for this aspect of the
projects.
Now I am totally open to the suggestion that I have obviously not grasped to
full features available to me in ADO.NET but it would seem that is, in some
respects, more difficult now that it was in ASP. The more complex the data
the more you are contrained by the generic nature of data displaying
webcontrols.
MattC
I am developing a timesheet system that collects information about employees
activities. In this I collect details about projects they do work for, what
type of work, how long, when etc etc.
For distributed data input/storage and display I am happy using ASP.NET.
However ther eis one aspect of the project I am not entirely comfortable
with, report production. The requirement is to produce 6 or 7 reports that
view certain aspects of the data in particular layouts with certain totals,
averages, etc. Getting the data was not to difficult although the ROLLUP
and CUBE function in SQL Server did tend to have a habit of producing more
results rows than I needed.
I wont begin to mention my woes at creating my own version of the Access
TRANSFORM/PIVOT functions.
So in my BLL I began stripping rows and creating new tables to pass on to my
Presentation layer. However once here I found my self having to perform all
sorts of webcontrol acrobatics to get my data to display how I want it. A
combinational mixture of nested repeaters/datagrid/datalists aloong with
many datarelations to link results sets from several complex sql statements,
then there was the color fomatting, in comes the use of the ItemDatabound
event to check rows as they are added.
By then end I have several reports that while look good, have completely
destroyed any sense of object modelling in that area of the code, I
specialised where I could but the difference in data returned made it near
impossible to find any common means to create a useful hierarchy.
So my question after all this is: Is ASP.NET suited to producing/displaying
reports of a complex nature in a way that can be easily maintained? Would
something like Crystal reports be better used for this aspect of the
projects.
Now I am totally open to the suggestion that I have obviously not grasped to
full features available to me in ADO.NET but it would seem that is, in some
respects, more difficult now that it was in ASP. The more complex the data
the more you are contrained by the generic nature of data displaying
webcontrols.
MattC