Hi Nancy,

How about a spreadsheet? You could whip one up in half an hour, charging your customer much more of course <g>. Seriously, if you want to keep your data normalized, you could translate the data in/out of the denormalized table as needed. At that point, the table is just an aid in presenting the UI you want, but the underlying data stays nice and normalized for other purposes. Of course, the translation could get hairy, which defeats KISS.

>I'm struggling with what the best implementation would be for a particular situation.
>
>The data is normalized timesheet data with hours entered for each day worked in a month for varying tasks.
>
>The customer would like to see the tasks listed in the left most column, with the days 1-31 shown across the top in the first row. This is how they're used to tracking their time on paper forms.
>
>The list of tasks isn't fixed. And the emp. won't enter hours for every task, maybe one or two. They'd like to see a total in the right-most column for each task, and an overall total for the month. A summary row for each day would be nice, too.
>
>My problem is that I keep trying to be clever (a mistake, of course) and keep coming back to KISS. The KISS solution seems to me to be a straightforward issue of creating a denormlized table with 32 attributes (task, and 31 days) for each possible task. Then I can display it in a datagrid. There are problems of course with this. Not least of which is that 31 columns won't even come close to nicely displaying on monitor so I'd need to "freeze" the left-most task column so it always displays.
>
>The customer will not want the employees to have to mouse to click and choose the tasks from a drop or navigate in a calender to pick the day to enter time for. They'll probably click in the first day of the month they have time for and tab thereafter.
>
>What do you all think is my best bet? Create a denormalized datatable to collect the time in and bind to a datagrid?