>Personal opinion is that have the 'system' help by managing things like 'delete flags' is opening the door to difficult debugging. Given the nature of a global state like DELETED ON/OFF simple errors of ommission by anyone working on the app can lead to long hours of ....... I have always thought it best to take responsibility for the state of data rows and add a rstatus c(1), added_on date, and added_by (userid). This way you always run with SET DELETE OFF (Rushmore likes this) and the one char rstatus allows 255 states for a row from active to voided, pending, etc. You also get to track data much like bank transactions (who did it when) s all applications-nothing is ever DELETED and history can always be recovered, backup and archive are similarly handled.
>Just my opinion - all style are valid here.
>Gary
I agree with this if you absolutely need an audit trail type of system. But if you don't why hang on to deleted data if you don't need it. Delete and pack should have a purpose after all.