> There's no way to programmatically determine which of these cases it is. There is no need to programmatically determine which case it is. You're way over th

> There's no way to programmatically determine which of these cases it is. There is no need to programmatically determine which case it is. You're way over thinking the problem. > NULL simply has no consistent semantics in a DB model. Yes, it's the lack of a value. If you have an end_time field and you don't have an end_time and column doesn't allow NULLs, what do you put in there? It's a simple question. If you put any kind of valid value in there (which you have to do) then you'll be wrong. > Or does it mean the process failed to write it's end state (for instance, if the machine crashed?) You sure as hell better be using transactions to maintain consistency. This has nothing to do with the problem. If you do it this way that's just wrong. Has nothing to do with nulls. If you had a perfectly non-null FLAG you'd have the same problem. > Which means this field no longer models the end time of the process While the process is running it doesn't have an end_time, so what do you put in this field?