RE: Is the table created or not?

QTEMP? Commitment control? Those are about the only things that come to mind.



-----Original Message-----
From: John Yeung [mailto:gallium.arsenide@xxxxxxxxx]
Sent: Thursday, September 06, 2018 5:55 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Is the table created or not?

I am at my wits' end. Within a large application, I've got some SQL which creates a table (which will be used for output later) by selecting columns from another table (which serves as a kind of data dictionary of all possible columns).

This has been working for years, and now when I make some changes to the application, it doesn't work anymore.

We don't have journaling, so the SQL always gives me

SQLState: 01567, Error code: 7905
Table MYFILE in MYLIB created but was not journaled.

But that has always been the case; the application would simply carry on despite the lack of journaling, and make use of MYLIB/MYFILE just fine.

However, with my recent changes, the table doesn't even seem to be created. I get the same message (that it's created but not journaled), yet the table's not there.

Maybe more precisely, the *file* is not there. Immediately after attempting to create the table, I check for existence of the file object, and the result is negative. But I can still query the table with SQL to get a row count (which will be zero). A table that doesn't exist shouldn't be able to be queried at all.

I know I haven't given many details and no code at all, but it's in iSeriesPython. I guess I'm mainly wondering if anyone's ever encountered anything like this before, or has any ideas of what to look for.

Oh, I should mention that when I pull the suspect code out of the application and into a testing stub, or into STRSQL, it works fine.
And as I said, it's still working in the current version of the application, just not in my new, modified version.

John Y.