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 ofis 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"