jw@pan.UUCP (Jamie Watson) (09/16/88)
The Informix 4gl manual describes use of the 'formonly' field type, with
several associated keywords ("type", "like" and "not null"). However, the
4gl forms compiler *only* accepts the "type" keyword as the first keyword
following the field-name. THis means that it is not possible to declare
formonly fields that are "like" some database field, and it is not possible
to declare formonly fields "not null" without declaring a type for them.
The examples given in the 4gl manual conveniently do not use any of the
optional keywords in the formonly declaration.
jwbrianc@daedalus (Brian Colfer) (09/20/88)
In article <475@pan.UUCP> jw@pan.UUCP (Jamie Watson) writes: > >The Informix 4gl manual describes use of the 'formonly' field type, with >several associated keywords ("type", "like" and "not null"). However, the >4gl forms compiler *only* accepts the "type" keyword as the first keyword >following the field-name. THis means that it is not possible to declare >formonly fields that are "like" some database field, and it is not possible >to declare formonly fields "not null" without declaring a type for them. > >The examples given in the 4gl manual conveniently do not use any of the >optional keywords in the formonly declaration. Well I tried this effect... The LIKE works fine I think JW's confusion on this is not reading the manual quite carefully enough: fieldtag = FORMONLY.field-name [TYPE [ data-type | LIKE table.column] ] [NOT NULL] [, attributes]; ^ ^ So this works: database test ... f1 = formonly.foo type like test_tbl.col_one; but maybe I'm missing something because this doesn't: database test ... f1 = formonly.foo type like test_tbl.col_one not null; or even database test without null input ... f1 = formonly.foo type like test_tbl.col_one not null; ------ If it is a bug... maybe '.03 release has the fix ... just got it this morning. =============================================================================== Brian : UC San Francisco :...!{ucbvax,uunet}!daedalus.ucsf.edu!brianc Colfer : Dept. of Lab. Medicine : brianc@daedalus.ucsf.edu : PH. 415-476-2325 : BRIANC@UCSFCCA.BITNET ===============================================================================
aland@infmx.UUCP (Dr. Scump) (09/24/88)
In article <475@pan.UUCP>, jw@pan.UUCP (Jamie Watson) writes: > > The Informix 4gl manual describes use of the 'formonly' field type, with > several associated keywords ("type", "like" and "not null"). However, the > 4gl forms compiler *only* accepts the "type" keyword as the first keyword > following the field-name. THis means that it is not possible to declare > formonly fields that are "like" some database field, Wrong. [E5] The exact syntax, quoted from page 3-16 of the manual: fieldtag = FORMONLY.field_name [TYPE [data_type | LIKE table.column]] [NOT NULL] [,attr_list]; This means that you can define it with a data type -or- LIKE a database column. Try this definition in a form using the demo "stores" database: f009 = formonly.phone2 TYPE LIKE customer.phone, reverse; perhaps you said just "LIKE" instead of "TYPE LIKE". > and it is not possible > to declare formonly fields "not null" without declaring a type for them. True enough, but you can't use a field with no type! Are you protesting the need to say "TYPE CHAR NOT NULL" (as per the documentation, see above) instead of "TYPE NOT NULL"? The syntax above shows that one or the other is required. ( [ a | b ] means "choose from a or b, but you must choose 1" -- If the whole entry was optional, it would say {[ a | b ]} ) > The examples given in the 4gl manual conveniently do not use any of the > optional keywords in the formonly declaration. The following example is in the orderform.per demo form (and Appendix A, p24): f019 = formonly.t_price TYPE MONEY; I agree that there should be more. I have examples that I can email upon request. > 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"
aland@infmx.UUCP (Dr. Scump) (09/24/88)
In article <1363@ucsfcca.ucsf.edu>, brianc@daedalus (Brian Colfer) writes: > > Well I tried this effect... The LIKE works fine I think JW's confusion > on this is not reading the manual quite carefully enough: > > fieldtag = FORMONLY.field-name > [TYPE [ data-type | LIKE table.column] ] [NOT NULL] [, attributes]; > ^ ^ > So this works: > > database test > ... > f1 = formonly.foo type like test_tbl.col_one; > > but maybe I'm missing something because this doesn't: > > database test > ... > f1 = formonly.foo type like test_tbl.col_one not null; > If it is a bug... maybe '.03 release has the fix ... just got it > this morning. I think it's a documentation error. Since NOT NULL is part of the column type, it shouldn't be used with a LIKE. I think that this syntax: fieldtag = FORMONLY.field_name [TYPE [data_type | LIKE table.column]] [NOT NULL] [,attr_list]; ^^^^^^^^^^ should read: fieldtag = FORMONLY.field_name [TYPE [data_type [NOT NULL] | LIKE table.column]] [,attr_list]; ^^^^^^^^^^ I tested this to make sure. If you define a formnly field LIKE a column and that column is NOT NULL, the formonly field properly picks up the NOT NULL characteristic. If you define a formonly field LIKE a column that allows nulls, the formonly field likewise allows nulls. If you omit the whole TYPE entry, the field type defaults to CHAR. > Brian : UC San Francisco :...!{ucbvax,uunet}!daedalus.ucsf.edu!brianc > Colfer : Dept. of Lab. Medicine : brianc@daedalus.ucsf.edu > : PH. 415-476-2325 : BRIANC@UCSFCCA.BITNET P.S.: nice example of space/null management in your previos posting... -- 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"