>
>This is a bad practice, period. It's myopic and the expressed attitude here is full of hubris.
>

Thanks.
Rembrandt was myopic and full of hubris.

>"Based on observations?" Have you ever dealt with incremental extracts in an ETL environment, where the source system decided to delete rows?

Yes, and the programmer who doesn't recognize the difference between a row that can be deleted and one that shouldn't is a coder, not a programmer.


>Difference between a professional and "all others" - adhering to good practices even when it doesn't seem like there's any reason. You shouldn't delete rows in an OLTP/production system. Period.
>

I've had my share of grief with systems over the years and I've had more grief from failing to recognize deleted rows that shouldn't have been there than the reverse.

I recently inherited a SQL Server system that had its origins in .dbf's.
In order to preserve the .dbf DELETED() feature, the designer put a bit column in each row indicating that the row had been deleted.

I submit that the client will lose more money paying programmers who waste time avoiding that debris than it would lose had the debris never been there.