SQL commands over ODBC: Changing tables triggers inquiry messages

Hello,

when someone changes a DDL table containing data and wants to delete a field through an ALTER TABLE statement via ODBC, said change fails. I don't have the precise error message at hand, though.

I had a similar experience some time ago, when developers tried to drop entire tables or libraries. My workaround was to create a separate job description for qzdasoinit, setting inqmsgrpy to *dft. Fortunately, the message default was to continue.

Apparently, this doesn't fix the issue when trying to drop only a field. I assume, that triggers another inquiry message ID, and the default answer is to disallow the request. If I run the SQL in question in an interactive 5250 session's strsql, I see the generated inquiry message, and can answer properly to ignore the warning, so the request is fulfilled. Of course, someone connecting to IBM i purely with ODBC will never see this message.

I probably can find a way to work around this specific issue. However, I wonder how other shops deal with such issues, where developers solely access IBM i via ODBC. How are "5250 ignorant" developers supposed to talk to the database entirely through ODBC, without the need of an admin who regularly helps them to do things triggering an inquiry message? Any helpful insights? Thanks!

:wq! PoC