RE: SQL DROP field without overriding message replies?

No it wouldn't. When you run the sql to drop a column it doesn't precheck
all rows to see if that column is empty. It doesn't even check all rows
to see if the column's null indicator is on. And there's not a table
attribute that says "there's at least 1 row containing a value for
ColumnX". It just says if you drop this column there's a potential for
data loss.

Here's an idea. Use a QSYSOPR monitor that says if that message appears
then automatically take the appropriate option. Perhaps done with iNav,
Robot, MessengerPlus, etc.

But you run into this problem. Suppose David is a software developer who
creates products going out to multiple customers. Can you assume that all
of them will have a message queue monitoring solution? Will all of them
be ok with you modifying job descriptions or whatever it takes to use
system reply list entries? Will all of them be ok with you adding system
reply list entries? Will they just deal with it, like the QAQQINI entries
strongly suggested to us by our ERP vendor? Someone in David's shoes may
decide, that, yes, it's more of a hassle to make a stored procedure for
every stupid thing but it's less hassle than beating a customer into
submission to change their environment.


Rob Berendt