On 24-Apr-2014 13:40 -0500, Dale Janus wrote:
I am slowly converting all our files from DDS to DDL.
  Why?  Be sure the change is for specific\explicit reasons and the 
[potentially negative] effects are fully understood; i.e. beware of 
making change simply for the sake of making change.
I have a file I want to add a new field to. I originally created the
file with DDL in system i navigator (V7R1M0), so I navigate to the
file, chose definition and created a new numeric field, remove
nullable from the default and click ok. Field is added. But when I am
at the file level and click ok, I get this error:
 SQL State: 58004  Vendor Code: -901
Message: [SQL0901] SQL system error. <<SNIP>> previous message
identifier was CPF5104. Internal error type 4406 has occurred.
<<SNIP>>
job log shows CPF2972 error writing to member and CFP5029 data
mapping error. (I can't copy the job log)
  The reason code [or return code] for a msg CPF5035 [as described by 
the msg CPF5029] should appear including other details that further 
diagnose the condition; that should be RC19 for RRN=1 for a NULL value 
encountered.  In other words, additional details are all moot, because 
the problem will always be the same for every file with that same 
scenario, whenever the file has at least one row; i.e. no data, no 
problem, but with data there is always a problem.
  Quite probably the msg SQL0901 [an effective SQL "function check"] is 
the wrong result, and -407 msg SQL0407 should have been the result for 
the failing request.
If we add the field as "null with default 0", it adds ok. Then we go
back and modify and remove the null. This is a long way around. (I am
working on a test file that has data in it.)
  Should work fine if added originally as "not null with default 0"; 
i.e. no reason to remove null-ability, never add the capability.
If we use straight SQL, it works ok. My partner is good with SQL, I
am not, I need navigator's help.
  Probably the "straight SQL" was not an equivalent scenario, due to a 
lack of any data having been added to the file, to properly mimic the 
original failing scenario; e.g.:
     create table qtemp/prueba (old_col char not null)
     ;
     insert into  qtemp/prueba values(1)
     ; -- omit INSERT, and there is no error in this scenario
     alter  table qtemp/prueba add column new_col char
     ; -- need not be a numeric data type to see failure
     alter  table qtemp/prueba
            alter column new_col set data type char not null
     ; -- expected to fail per NULL value(s)
So what is happening with system i navigator and SQL and NULL?
  Seems the request fails as expected, though possibly unexpectedly 
with a generic -901 condition instead of [the more likely as expected] 
sqlcode=-407 sqlstate=23502
     drop   table qtemp/prueba
     ; -- do not fall-over prior test-case
     create table qtemp/prueba (old_col char not null)
     ;
     insert into  qtemp/prueba values(1)
     ; -- even with INSERT this scenario works fine
     alter table qtemp/prueba
           add new_col decimal not null with default 0
     ; -- new column gets zero as default, not the NULL value
As an Amazon Associate we earn from qualifying purchases.