>>>>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.
>
>Thanks, deleting all source and then adding back everything could work, but could possibly lead to a lot of deleted records. I'll have to consider if this will cause a problem with space and having to pack the files regularly.

You could recycle the deleted records, because you would overwrite the entire row.