>Displaying it in this new format and then massaging it back to save in my existing table will take some major fiddling/programming, so I am considering de-normalising my table to something like this:
>
>EmployeeID
>LocationID
>Date
>MondayStart
>MondayEnd
>TuesdayStart
>TuesdayEnd
>
>and so on.
>
>What do you all think? Is this a good enough reason to de-normalise?

I wouldn't. I'd have a cursor which would have those fields, and would populate it from the regular tables and at the end of session save everything back into regular tables, with clean cut pieces of code for each of these operations. I don't care if that code is heavy or ugly - it has to be, this is the rug where you swipe the dirt. But then you keep your database clean and don't encounter the ugliness there, your life doesn't get unnecessarily complicated, and the ugly fields don't spread.

The nice side of this "do not touch your tables" is that you don't disturb your original code, only have a different form - IOW, presentation layer. Which can be replaced. Imagine if you did something to your tables and in the end they didn't like it and want it like it was before. What then? If you don't touch the rest, you simply show the old form instead of the new one and go take a nap :).

I've seen such a denormalized table, for bread delivery. The rows were the types of bread, and the columns were the shops. Well, that was wrong (there were never more than 20-30 kinds of bread made in a day, but the number of shops grew toward 100). Then it got worse, as some shops asked for two or sometimes three deliveries in a day, so that was more columns. Then they'd make a copy of the table for the next day.

Soon they ran out of disk space. The table's zip factor was about 1% - regularly it's about 10% for dbf.