Re: Foreign key causing Error:55019 Message:SQLSTATE=55019 SQLCODE=-7008

On 23-Oct-2015 15:21 -0500, Justin Dearing wrote:

<<SNIP>> if I wanted to make the journal in SQL, are my two best
options QCMDEXEC and registering CRTJRN as a stored procedure? If
Journaling is a feature of tables that's been around since at least
v5, why can't I control it with CREATE/ALTER TABLE? Seems like a
silly thing to expect me to use CL for, if I'm supposed to use SQL
DDL to make the Physical File.

If the library was created with CREATE COLLECTION [IIRC synonymous with both CREATE SCHEMA and CREATE DATABASE] then there would have been a QSQJRN Journal (*JRN) object created implicitly [via the Create Journal (CRTJRN) command running as part of the CREATE] to which the CREATE TABLE implicitly then would have been journaled; i.e. there is no requirement to use the CL, if operating purely within the SQL environment. Having to run the CL would have been a side effect of CREATE TABLE into a library created *outside* of the SQL [or someone had /broken/ the SQL-ness of the library either by Delete Journal (DLTJRN) issued against the QSQJRN *JRN object, or perhaps by someone having modified the library with either the addition of a QDFTJRN *DTAARA object or via the STRJRNLIB command].

The newer [and better] way, for an existing library created with Create Library (CRTLIB) is to issue the Start Journal Library (STRJRNLIB) command against the library specifying that, to what journal [and] that the files should be implicitly journaled. Better, because a journal name other than the duplicitous name QSQJRN can be chosen for logging; for journal recovery purposes [albeit rarely ever an issue], the journal names are ideally unique across the system. Anyhow, just like the implicit Start Journal Physical File (STRJRNPF) effected when the library started\remained a legitimate SCHEMA, the STRJRNLIB can make the non-SCHEMA library operate quite effectively the same as the SCHEMA, but the files /connecting to/ a different Journal.