Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!pyramid!infmx!aland
From: aland@infmx.UUCP (Dr. Scump)
Newsgroups: comp.databases
Subject: Re: Informix 4gl - form input default broken
Summary: SPERFORM and 4GL handle this *identically*
	 Define the column NOT NULL if blanks wanted instead of nulls
Message-ID: <462@infmx.UUCP>
Date: 24 Sep 88 05:25:53 GMT
References: <473@pan.UUCP>
Organization: Informix Software Inc., Menlo Park, CA.
Lines: 107

The following is my own personal followup and does not represent the
position of Informix.  This and subsequent followups are in defense
of certain personal attacks. 

In article <473@pan.UUCP>, jw@pan.UUCP (Jamie Watson) writes:
> 
> Given a database with a field declared as char(1), and a form to input
> that field with the following specifications:
> 
>     include = ("Y","N"," "), default = " "
> 
> When a 4gl program does input with this form, the default value is not
> accepted.  That means that attempting to terminate input produces the
> message "This value is not among the valid possibilities".

A default value of " " (space) is properly accepted iff the column is
defined NOT NULL and WITHOUT NULL INPUT is used in the form header.

The inability to control this behavior on a field-by-field basis is 
a deficiency, recorded as a bug (#2279);  e.g., you cannot have a
field with nothing in it interpreted as space (vs. NULL) unless you
use WITHOUT NULL INPUT on the form as a whole in the current release.
Using the above combination causes "non-values" to be treated as blanks,
not nulls.  Otherwise, they are nulls.

> Using the *identical* form with the Informix-SQL Perform form processor
> everything works correctly.

Not true. [E1]  SPERFORM and 4GL hold the same rules.  I just verified 
this in the current release (2.10.03 / 1.10.03).  The only way that this
could "work correctly" in Perform is if you have WITHOUT NULL INPUT and
a NOT NULL column.  If you had the same in 4GL, the behavior would
be the same.

> In fact what is apparently happening is that the field is getting a null
> value by default, instead of a space, because adding null to the include
> list causes the form to accept the default value under 4gl.

Also not true. [E2]  The default of  is not "being accepted";
the input variable value is NULL, not space.  By adding NULL to the
INCLUDE list you are allowing the NULL to come through.  Try the
following sample:  (sorry for the bandwidth, but I felt an example 
was important to reduce disinformation):
--------------------------------------------------------------------
{schema}
create database jw;
create table tab2 (col1 integer, col2 char(1), col3 char(1) NOT NULL);

{jw14.per}
database jw without null input
screen
{
col1               [f000       ]
col2               [a]
col3               [b]
}
end
tables
tab2
attributes
f000 = tab2.col1;
a = tab2.col2, include = ("Y", "N", " ", NULL), default = " ";
b = tab2.col3, include = ("Y", "N", " "), default = " ";
end

{jw1.4gl}
database jw

main

define r1 record like tab2.*,
       c2s char(5),
       c3s char(5)

open form jw1 from "jw14"
display form jw1
input by name r1.* 

if r1.col2 is null then
   let c2s = "NULL"
else
   let c2s = "BLANK"
end if
if r1.col3 is null then
   let c3s = "NULL"
else
   let c3s = "BLANK"
end if

message "col 2 is ", c2s, "   col 3 is ", c3s
sleep 2
end main
--------------------------------------------------------------------
To verify that Perform does the same thing:
Using the same form (recompile in ISQL) add a row, spacing through
both col2 and col3.  Using RDSQL, select * from tab2 where col2 IS
NULL -- you will see the row.  Select where col3 IS NULL -- you will
not see the row.  Col3 gets  because it was defined NOT NULL
and WITHOUT NULL INPUT was used in the form.

> jw

-- 
 Alan S. Denney  |  Informix Software, Inc.  |  {pyramid|uunet}!infmx!aland
 Disclaimer: These opinions are mine alone.  If I am caught or killed,
             the secretary will disavow any knowledge of my actions.
 Santos' 4th Law: "Anything worth fighting for is worth fighting *dirty* for"