jw@pan.UUCP (Jamie Watson) (09/14/88)
The Informix 4gl "construct" statement is broken in such a way as to render
it useless anywhere the "DBDATE" environment variable is used to change the
default date format.
We use "DBDATE=DMY2."; this works perfectly for output with the display,
display array and print statements, and for input with the input and
input array statements. Input with the construct statement apparently
doesn't respect this setting, though. The following program shows the
problem:
database fooey
main
define
d date,
q, s char(512)
open form f from "broken"
display form f
input d from broken
construct by name q on broken
end main
On running this program, I can type "13.9.88" at the input statement,
and it works fine. I then type exactly the same thing at the construct
statement, and I get "Error in field".
Apparently we have to tell our customers that they can type dates in
European format for input, but they have to use U.S. format for any
queries???
jwdberg@cod.NOSC.MIL (David I. Berg) (09/16/88)
In article <471@pan.UUCP>, jw@pan.UUCP (Jamie Watson) writes: > > The Informix 4gl "construct" statement is broken in such a way as to render > it useless anywhere the "DBDATE" environment variable is used to change the > default date format. > I echo Watson's concern. My users can use military format for entering dates (eg. 13sep88 or 13 sep 88 etc.) on INPUT but must use mm/dd/yy on queries. -- David I. Berg (dberg@nosc.mil) GENISYS Information Systems, Inc., 4250 Pacific Hwy #118, San Diego, CA 92110 MILNET: dberg@nosc.mil UUCP: {ihnp4 akgua decvax dcdwest ucbvax}!sdcsvax!noscvax!dberg
aland@infmx.UUCP (Dr. Scump) (09/27/88)
In article <1214@cod.NOSC.MIL>, dberg@cod.NOSC.MIL (David I. Berg) writes: > In article <471@pan.UUCP>, jw@pan.UUCP (Jamie Watson) writes: > > The Informix 4gl "construct" statement is broken in such a way as to render > > it useless anywhere the "DBDATE" environment variable is used to change the > > default date format. > > I echo Watson's concern. My users can use military format for entering > dates (eg. 13sep88 or 13 sep 88 etc.) on INPUT but must use mm/dd/yy > on queries. > > David I. Berg (dberg@nosc.mil) > GENISYS Information Systems, Inc., 4250 Pacific Hwy #118, San Diego, CA 92110 > UUCP: {ihnp4 akgua decvax dcdwest ucbvax}!sdcsvax!noscvax!dberg Sounds like you both may have old versions. This was reported over a year ago and was fixed two versions ago (in 1.10.00). I tested it in the current version of I4GL (1.10.03) and 1.10.00 and it seems to work fine using a DBDATE of "dmy2." There was a problem in an older version (1.00.05) that this would occur if DBDATE was used to change the order of month/day/year (a common need in Europe). Regards, Alan Denney -- 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"
jw@pan.UUCP (Jamie Watson) (09/30/88)
In article <467@infmx.UUCP> aland@infmx.UUCP (Dr. Scump) writes:
<Sounds like you both may have old versions. This was reported over a
<year ago and was fixed two versions ago (in 1.10.00). I tested it in
<the current version of I4GL (1.10.03) and 1.10.00 and it seems to work
<fine using a DBDATE of "dmy2."
I have I4GL version 1.10.00D on an IBM RT/PC, 1.10.00A on a Vaxstation,
and 1.10.00B on a Plexus P/20. All have exactly the problem I described
in my original posting. I am using DBDATE=DMY2.
jwdberg@cod.NOSC.MIL (David I. Berg) (10/05/88)
In article <467@infmx.UUCP>, aland@infmx.UUCP (Dr. Scump) writes: > In article <1214@cod.NOSC.MIL>, dberg@cod.NOSC.MIL (David I. Berg) writes: > > In article <471@pan.UUCP>, jw@pan.UUCP (Jamie Watson) writes: > > > The Informix 4gl "construct" statement is broken in such a way........ > > > ...it useless anywhere the "DBDATE" environment variable is used to change > > > the default date format. > ...this...was fixed two versions ago (in 1.10.00). I confess I never re-tested this since obtaining V1.1. It works as advertised. We are running I4GL V1.10.00C on a Zenith Z248 with Microport SysV V2.3. -- David I. Berg (dberg@nosc.mil) GENISYS Information Systems, Inc., 4250 Pacific Hwy #118, San Diego, CA 92110 MILNET: dberg@nosc.mil UUCP: {akgua decvax dcdwest ucbvax}!sdcsvax!noscvax!dberg
aland@infmx.UUCP (Dr. Scump) (10/06/88)
In article <1241@cod.NOSC.MIL>, dberg@cod.NOSC.MIL (David I. Berg) writes: > In article <467@infmx.UUCP>, aland@infmx.UUCP (Dr. Scump) writes: > > In article <1214@cod.NOSC.MIL>, dberg@cod.NOSC.MIL (David I. Berg) writes: > > > In article <471@pan.UUCP>, jw@pan.UUCP (Jamie Watson) writes: > > > > The Informix 4gl "construct" statement is broken in such a way........ > > > > ...it useless anywhere the "DBDATE" environment variable is used to change > > > > the default date format. > > > > ...this...was fixed two versions ago (in 1.10.00). > > I confess I never re-tested this since obtaining V1.1. It works as advertised. > We are running I4GL V1.10.00C on a Zenith Z248 with Microport SysV V2.3. > David I. Berg (dberg@nosc.mil) Thanks for the confirmation. (Are you listening, Jamie?) Jamie, if you are still having problems with it, make sure of the following: 1) make sure DBDATE is set *exactly* to a correct format (e.g. dmy2. ). No quotes or other special characters should appear within the environment variable itself. (I tested "dmy2." in both uppercase and lowercase -- it worked both ways.) 2) make sure DBDATE is *exported*. 3) if using dates in forms, make sure you have the correct FORMAT clause on the field attribute, e.g. f001 = person.birthdate, format = "dd.mm.yy"; otherwise, the standard date format ("mm/dd/yy") is assumed. 4) make sure the form field is wide enough to accomodate the field (8 chars wide if using 2-digit years, 10 chars wide if using 4-digit years). 5) if the field is a FORMONLY field, make sure it is defined TYPE DATE (or TYPE LIKE <date column>). 6) in the case of 4GL CONSTRUCTs, carefully check your CONSTRUCT statement against the form fields it references. I'll bet one of the above is the problem. -- 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"
jw@pan.UUCP (Jamie Watson) (10/11/88)
In article <497@infmx.UUCP> aland@infmx.UUCP (Dr. Scump) writes: >Jamie, if you are still having problems with it, make sure of the >following: > 3) if using dates in forms, make sure you have the correct FORMAT > clause on the field attribute, e.g. > f001 = person.birthdate, format = "dd.mm.yy"; > otherwise, the standard date format ("mm/dd/yy") is assumed. Wait a minute, why is this necessary? I just created a tiny test form and a 4gl program to go with it, and sure enough, if I add a format specification to the form as you indicate, the construct statement in the 4gl program works. I certainly don't see why it is necessary, though; in fact, it looks to me like it defeats the purpose of the DBDATE environment variable, because it is hard-coding the date format into the form! Also, Perform get this right without having the date format hard-coded into the form, so why doesn't 4gl? Here is a summary: - Create a database with one table, containing one field, of type date - Create (or generate) a form for that table/field. Do not include a format specification for the date. - Set DBDATE to DMY2. and run the form with Perform. All input for add, update and query, will be acceptd in DMY format. - Change DBDATE to MDY2. and run the form. All input will be accepted in MDY format. So far, this is exactly what I expected to happen. - Write a 4gl program with a construct statement on that field, and run it with DBDATE set to DMY2. Input will only be accepted when given in MDY format; this is where I think 4gl is failing. - Edit the form, adding format = "dd.mm.yy" to the field, and compile it again. - Run the 4gl program again, with DBDATE still set to DMY2. Input is now accepted in DMY format. So far, so good. - Change DBDATE to MDY2. and run the 4gl program again. Input is still only accepted in DMY format. - Try running the form with Perform again, with the format specification included. Input is always accepted in DMY format, regardless of the setting of DBDATE. So, this provides what looks like a workaround to the problem, but I really don't understand if this is the "real solution" or not. Is it really supposed to be necessary to specify the format in the form file, if it is other than the default? If so, why does Perform work correctly without this specification, but 4gl doesn't? >I'll bet one of the above is the problem. Well, sort of. At least it lead to a workaround which I can live with. Thanks. jw
aland@infmx.UUCP (Dr. Scump) (10/15/88)
In article <491@pan.UUCP>, jw@pan.UUCP (Jamie Watson) writes: > In article <497@infmx.UUCP> aland@infmx.UUCP (Dr. Scump) writes: > >Jamie, if you are still having problems with it, make sure of the > >following: > > 3) if using dates in forms, make sure you have the correct FORMAT > > clause on the field attribute, e.g. > > f001 = person.birthdate, format = "dd.mm.yy"; > > otherwise, the standard date format ("mm/dd/yy") is assumed. > > Wait a minute, why is this necessary? I just created a tiny test form > and a 4gl program to go with it, and sure enough, if I add a format > specification to the form as you indicate, the construct statement > in the 4gl program works. I certainly don't see why it is necessary, > though; in fact, it looks to me like it defeats the purpose of the > DBDATE environment variable, because it is hard-coding the date format > into the form! > ... > jw Yeah, I agree with you... technically, the general default date format is "mm/dd/yyyy", but it does seem somewhat arbitrary that DBDATE does not automatically override this default in FORM4GL. If you look at page 3-32R, you will see these examples using the date Sept. 15 1986: Input Result no FORMAT attribute "09/15/86" ... ... FORMAT = "dd-mm-yy" "15-09-86" Soooo, the documentation is *technically* correct (no flames please :-]), but this functionality is not explained well at all. In my opinion, it should have been stated in a Note at least, especially since the environment variable appendix entry on DBDATE implies that DBDATE alone should take care of default date formatting. If it makes you feel any better, this was changed in the current release (1.10.03) so that DBDATE *does* override the general default in FORM4GL. Therefore, the FORMAT="dd.mm.yy" would not be necessary in the current release. (I also tested this is the current DOS release [1.10.06], and it works the same as UNIX 1.10.03, in case you use DOS.) -- 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"