Another option of course is to make the column invisible in the client (whatever that client is) based on access rights, but that does require you to have control over the client side of things and that is very often no longer the case.
But when you blank the contents, there is always the worry that blank data may be offered back to you to store in your database. This would make saving data back into the database a lot trickier and you would have to apply the security while saving and do so on a column by column basis... If the column simply isn't there at all you should theoretically not be overwriting any database contents. You would however have to ensure once (before actually saving) that the "user" has proper access rights for each column in the temp-table/dataset that is to be applied to your database.The safe thing to do is to eliminate the column in building the temp-table or at least to blank the contents, even if the column still exists. That way, if you change UI technology or repurpose to send data to some other kind of agent which you don't control, the data simply won't be there. This centralizes the control.
The safe thing to do is to eliminate the column in building the temp-table or at least to blank the contents, even if the column still exists. That way, if you change UI technology or repurpose to send data to some other kind of agent which you don't control, the data simply won't be there. This centralizes the control.
Actually, the lazy way is to control the security in the data source. That way you only have to do it in one place and one time. In the UI you might have to do it multiple times ... and you have the possibility of someone doing something different on the client and violating your security. Control it at the source and you can be confident.
Why create the same temp-table in multiple places. Encapsulate the logic in a data source and put all logic about security control, updates, relational integrity, etc. there. Any place that needs it, accesses that one source.
Done any reading on OERA? This sort of layering is inherent in the approach. You don't want it in the UI especially since this year's ABL UI might be next year's WUI or you might be sending the data off to some other service or providing it via a web service or sending it to a Java client. If you have put all of the build and update logic in one place, then you can do all of that without touching the data source. Put it in the UI and you have to do it all over again for a different UI and you have the risk that someone will access the data outside of the expected channel and see what it is they shouldn't see.