RE: SQL DROP field without overriding message replies?

[rob@xxxxxxxxx]

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