RE: Date Function Usage

I do it all the time (no pun intended) - use string to date. [slaps own wrist] It's OK in one off SQL queries - provided you're always in the same environment; but bad in code - non-portable. (If memory of a previous posting is correct) Frankie is using DBDATE == DMY4. The String should read like "31/01/1999" - or whatever the required date is update transtemp set t_exdt= "31/01/1999" where year(t_exdt) < 1999 A better approach is to use the mdy function - it's environment independent. So ... update transtemp set t_exdt= mdy( 1, 31, 1999 ) where year(t_exdt) <1999 == off track == Thinking about that first line, my (antiquated) versions of dbexport and dbimport use dates structured as string - environment dependant. For *true* portability these ought to give a clue to this environment variable. Has this changed? (OK - a dbimport is sufficiently major to justify resetting DBDATE at runtime - but...) Any comments Jonathan? -----Original Message----- From: Art S. Kagel [mailto:kagel@bloomberg.net] Sent: 14 November 2000 03:19 To: informix-list@iiug.org Subject: Re: Date Function Usage The user's environment variable DBDATE controls string to date interpretation as well as date to string formatting. Art S. Kagel Frankie wrote: > > Dear all: > I have a sql syntax problem: > > update transtemp set t_exdt= "1999/01/01" where year(t_exdt) < 1999 > || || > Date Field How does "String Type"> transform to "Date Type"? > > Thank's for your help. > > -- > Frankie Ke > Colovos Machinery Corp > TEL:(04)4070810*203 FAX:(04)-4071129 > Email:kehunchi@cm1.hinet.net