Like last-week's post about commitment control in Python ibm_db, you may run in to this unexpected error as well:

>>> cur.callproc('qcmdexc', ('ADDLIBLE QIWS',))
('ADDLIBLE QIWS',)
>>> cur.execute("select * from qcustcdt")
Traceback (most recent call last):
  File "/QOpenSys/pkgs/lib/python3.6/site-packages/ibm_db_dbi.py", line 1254, in _prepare_helper
    self.stmt_handler = ibm_db.prepare(self.conn_handler, operation)
Exception: QCUSTCDT in KADLER type *FILE not found. SQLSTATE=42704 SQLCODE=-204

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/QOpenSys/pkgs/lib/python3.6/site-packages/ibm_db_dbi.py", line 1394, in execute
    self._prepare_helper(operation)
  File "/QOpenSys/pkgs/lib/python3.6/site-packages/ibm_db_dbi.py", line 1257, in _prepare_helper
    raise self.messages[-1]
ibm_db_dbi.ProgrammingError: ibm_db_dbi::ProgrammingError: QCUSTCDT in KADLER type *FILE not found. SQLSTATE=42704 SQLCODE=-204

When using the Python ibm_db package to interact with the Db2 for i database, you may run in to this error:

>>> cur.execute('insert into qtemp.foo values(1)')
Traceback (most recent call last):
  File "/QOpenSys/pkgs/lib/python3.6/site-packages/ibm_db_dbi.py", line 1311, in _execute_helper
    return_value = ibm_db.execute(self.stmt_handler)
Exception: Statement Execute Failed: FOO in QTEMP not valid for operation. SQLSTATE=55019 SQLCODE=-7008

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/QOpenSys/pkgs/lib/python3.6/site-packages/ibm_db_dbi.py", line 1396, in execute
    self._execute_helper(parameters)
  File "/QOpenSys/pkgs/lib/python3.6/site-packages/ibm_db_dbi.py", line 1321, in _execute_helper
    raise self.messages[-1]
ibm_db_dbi.ProgrammingError: ibm_db_dbi::ProgrammingError: Statement Execute Failed: FOO in QTEMP not valid for operation. SQLSTATE=55019 SQLCODE=-7008

QSH provides a wonderful utility called db2 which allows you to run SQL queries from within the QSH shell, but what if you're in a QP2TERM shell or using SSH - what then?

Today I got asked if you can index in to rows returned by ibm_db_dbi by column name. While this doesn't come out of the box, it can be done pretty easily.

In my last blog I showed how the LIBPATH gets used and also how the runtime search path in the binary gets used. LIBPATH is obviously set as an environment variable, but how does that runtime search path get generated? Let's explore!