Re: Odd default schema behavior with SQL MQT's

Is "first library on the library list" meant to imply *CURLIB as the first in the user\current [CUR above USR] portion of the library list? If not, then library QGPL should be the *CRTDFT for *SYSTEM naming with SQL, just as outside of the SQL.?

Note that for unqualified CREATE of INDEX and VIEW in *SYS naming, the dependent object is not created into the *CURLIB [nor generally the first library in the user library list], but into the library of the first based-on [database file] object referenced as target of the SELECT or the library of the physical data for the access path.

Since an MQT is not officially a dependent built over the data as with the VIEW and INDEX [i.e. it is physical data], QGPL as *CRTDFT seems like the proper effect for a CREATE when no *CURLIB. That is, whatever CREATE TABLE would effect when not an MQT. I would expect if the *CURLIB was established, then the claim that the TABLE is created into the "first library on the library list" [the CUR of *USRLIBL] would not differ between the MQT and the non-MQT CREATE TABLE. If the *CRTDFT is in effect, then the MQT & TABLE should both go into QGPL [which need not be in *LIBL at all], but a CREATE of a VIEW & INDEX could be into any library in *LIBL; i.e. where its [first] based-on file is located.

Regards, Chuck

David Gibbs wrote:

I just observed some very odd behavior regarding SQL MQTs &
DB2/400.

I'm running the RUNSQLSTM command, with the DFTRDBCOL parameter
set to *NONE, in an interactive job with a specific library list
set.

When I create a index, view, or table the PF or LF is created in
the first library on the library list.

If, however, I create a MQT with the same environment the MQT is
created in QGPL instead of the first library on the library list.