>>It shouldn't be that difficult to normalize/denormalize. It's done all the time.
>>
>
>Does this logic fit in with how you would approach it:
>
>User displays screen for a location and week:
>I pull out all the data from the underlying normalised table and massage it into how I need it.
>User updates a couple columns in one row, adds a new employee row and deletes another employee row, then saves.
>In the background I will have to:
>- detect what was changed in the columns and update the underlying rows in my normalised table, (if there was no entry for a particular day I'll have to add that row in)
>- then insert the appropriate rows for the newly added employee and
>- then delete the rows for the deleted employee
>
>Having not done this kind of coding in years, do I use GETFLDSTATE() to detect the changes and what type of change? Or is there something easier to use?

Perhaps not the most elegant but easiest approach would be deleting all corresponding records in the source table (depending on the selection in the UI) and recreate the records each time after save. That saves you the check for deleted or modified records. If you look for easy I think that is the easiest of all.

Alternatively you can use a combination of GetNextModified() (if Tablebuffering = 5) and GetFldState(). Handling deleted records could be a challenge, you can do a SQL Delete From using WHERE NOT EXISTS() and delete those records that do not have a corresponding record in the de-normalized display cursor.