Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!amdcad!sun!pitstop!sundc!seismo!uunet!mcvax!cernvax!pan!jw
From: jw@pan.UUCP (Jamie Watson)
Newsgroups: comp.databases
Subject: Re: Informix 4gl "construct" statement broken
Message-ID: <491@pan.UUCP>
Date: 11 Oct 88 14:54:04 GMT
References: <471@pan.UUCP> <1214@cod.NOSC.MIL> <467@infmx.UUCP> <1241@cod.NOSC.MIL> <497@infmx.UUCP>
Reply-To: jw@pan.UUCP (Jamie Watson)
Organization: Adasoft AG, Solothurn, Switzerland
Lines: 49

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