>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.

Excatly, this is a way of new problems. We have to rely on each programmers from the project and this situation can occur when one forgot to call the SQL with the additional tag.

So, in your case, you always worked with SET DELETE OFF. So, this mean you already had all those additional conditions everywhere in your SQLs, etc.