Oninit cdi / Archive
Talk to an expert →

Re: Use of Interval Datatype

Posted in 2008

Topics: Migration, Import/Export & Data Conversion, Platform-Specific Issues, Cloud, Docker & Containers

Jonathan Leffler — — source: Usenet: comp.databases.informix

On Tue, Apr 1, 2008 at 4:04 AM, Colin Dawson <cjd_1955@hotmail.com> wrote: > Am I being a bit stupid with this...... > > Informix 9.40.FC8X3 > Solaris 9 As you know from the other responses, you got confused looking for the error in the wrong place (the interval column when it was the datetime column that had the problem). SQLCMD said: sqlcmd.32: dtcvasc(): error -1264 for column log_time converting '11:19:03' to DATETIME HOUR TO MINUTE sqlcmd.32: error in line 1 of file xxx.unl I wonder how long it would have taken you to resolve the problem with those diagnostics. Looking at the data unloaded, though, I think - how quickly we forget the lessons of Y2K. After correcting the input data, the result I got out was: 1|2001-04-08|11:19|2031-03-08|server_name|db_name|tabname1|0:00:02.327| 2|2001-04-08|11:19|2031-03-08|server_name|db_name|tabname2|0:00:00.586| 3|2001-04-08|11:19|2031-03-08|server_name|db_name|tabname3|28:50:52.828| OK - so I'm weird (no sniggering in the back there - it's well known; see my signature) and run with DBDATE=Y4MD- and you don't, but it is still, IMNSHO, worth always showing 4 digits for the years, and will be for the next 7000 or so years (after which, you need to think about showing 5 digits for the years). -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2008.0229 -- http://dbi.perl.org/ "Blessed are we who can laugh at ourselves, for we shall never cease to be amused." NB: Please do not use this email for correspondence. I don't necessarily read it every week, even.

↪ replying to Jonathan Leffler
Paul Watson (Oninit) — — source: Usenet: comp.databases.informix

Jonathan Leffler wrote: > On Tue, Apr 1, 2008 at 4:04 AM, Colin Dawson <cjd_1955@hotmail.com> wrote: >> Am I being a bit stupid with this...... >> >> Informix 9.40.FC8X3 >> Solaris 9 > > As you know from the other responses, you got confused looking for the > error in the wrong place (the interval column when it was the datetime > column that had the problem). > > SQLCMD said: > > sqlcmd.32: dtcvasc(): error -1264 for column log_time converting > '11:19:03' to DATETIME HOUR TO MINUTE > sqlcmd.32: error in line 1 of file xxx.unl > > I wonder how long it would have taken you to resolve the problem with > those diagnostics. > > > Looking at the data unloaded, though, I think - how quickly we forget > the lessons of Y2K. > > After correcting the input data, the result I got out was: > > 1|2001-04-08|11:19|2031-03-08|server_name|db_name|tabname1|0:00:02.327| > 2|2001-04-08|11:19|2031-03-08|server_name|db_name|tabname2|0:00:00.586| > 3|2001-04-08|11:19|2031-03-08|server_name|db_name|tabname3|28:50:52.828| > > OK - so I'm weird (no sniggering in the back there - it's well known; > see my signature) and run with DBDATE=Y4MD- and you don't, but it is > still, IMNSHO, worth always showing 4 digits for the years, and will > be for the next 7000 or so years (after which, you need to think about > showing 5 digits for the years). > Maybe in 7000 years we should start storing the year in Hex then people would now I was born in a BAD year :) Cheers Paul

↪ replying to Jonathan Leffler
Paul Watson (Oninit) — — source: Usenet: comp.databases.informix

Jonathan Leffler wrote: > On Tue, Apr 1, 2008 at 4:04 AM, Colin Dawson <cjd_1955@hotmail.com> wrote: >> Am I being a bit stupid with this...... >> >> Informix 9.40.FC8X3 >> Solaris 9 > > As you know from the other responses, you got confused looking for the > error in the wrong place (the interval column when it was the datetime > column that had the problem). > > SQLCMD said: > > sqlcmd.32: dtcvasc(): error -1264 for column log_time converting > '11:19:03' to DATETIME HOUR TO MINUTE > sqlcmd.32: error in line 1 of file xxx.unl > > I wonder how long it would have taken you to resolve the problem with > those diagnostics. > > > Looking at the data unloaded, though, I think - how quickly we forget > the lessons of Y2K. > > After correcting the input data, the result I got out was: > > 1|2001-04-08|11:19|2031-03-08|server_name|db_name|tabname1|0:00:02.327| > 2|2001-04-08|11:19|2031-03-08|server_name|db_name|tabname2|0:00:00.586| > 3|2001-04-08|11:19|2031-03-08|server_name|db_name|tabname3|28:50:52.828| > > OK - so I'm weird (no sniggering in the back there - it's well known; > see my signature) and run with DBDATE=Y4MD- and you don't, but it is > still, IMNSHO, worth always showing 4 digits for the years, and will > be for the next 7000 or so years (after which, you need to think about > showing 5 digits for the years). > Maybe in 7000 years we should start storing the year in Hex then people would now I was born in a BAD year :) Cheers Paul

↪ replying to Jonathan Leffler
Paul Watson (Oninit) — — source: Usenet: comp.databases.informix

Jonathan Leffler wrote: > On Tue, Apr 1, 2008 at 4:04 AM, Colin Dawson <cjd_1955@hotmail.com> wrote: >> Am I being a bit stupid with this...... >> >> Informix 9.40.FC8X3 >> Solaris 9 > > As you know from the other responses, you got confused looking for the > error in the wrong place (the interval column when it was the datetime > column that had the problem). > > SQLCMD said: > > sqlcmd.32: dtcvasc(): error -1264 for column log_time converting > '11:19:03' to DATETIME HOUR TO MINUTE > sqlcmd.32: error in line 1 of file xxx.unl > > I wonder how long it would have taken you to resolve the problem with > those diagnostics. > > > Looking at the data unloaded, though, I think - how quickly we forget > the lessons of Y2K. > > After correcting the input data, the result I got out was: > > 1|2001-04-08|11:19|2031-03-08|server_name|db_name|tabname1|0:00:02.327| > 2|2001-04-08|11:19|2031-03-08|server_name|db_name|tabname2|0:00:00.586| > 3|2001-04-08|11:19|2031-03-08|server_name|db_name|tabname3|28:50:52.828| > > OK - so I'm weird (no sniggering in the back there - it's well known; > see my signature) and run with DBDATE=Y4MD- and you don't, but it is > still, IMNSHO, worth always showing 4 digits for the years, and will > be for the next 7000 or so years (after which, you need to think about > showing 5 digits for the years). > Maybe in 7000 years we should start storing the year in Hex then people would now I was born in a BAD year :) Cheers Paul

↪ replying to Jonathan Leffler
Paul Watson (Oninit) — — source: Usenet: comp.databases.informix

Jonathan Leffler wrote: > On Tue, Apr 1, 2008 at 4:04 AM, Colin Dawson <cjd_1955@hotmail.com> wrote: >> Am I being a bit stupid with this...... >> >> Informix 9.40.FC8X3 >> Solaris 9 > > As you know from the other responses, you got confused looking for the > error in the wrong place (the interval column when it was the datetime > column that had the problem). > > SQLCMD said: > > sqlcmd.32: dtcvasc(): error -1264 for column log_time converting > '11:19:03' to DATETIME HOUR TO MINUTE > sqlcmd.32: error in line 1 of file xxx.unl > > I wonder how long it would have taken you to resolve the problem with > those diagnostics. > > > Looking at the data unloaded, though, I think - how quickly we forget > the lessons of Y2K. > > After correcting the input data, the result I got out was: > > 1|2001-04-08|11:19|2031-03-08|server_name|db_name|tabname1|0:00:02.327| > 2|2001-04-08|11:19|2031-03-08|server_name|db_name|tabname2|0:00:00.586| > 3|2001-04-08|11:19|2031-03-08|server_name|db_name|tabname3|28:50:52.828| > > OK - so I'm weird (no sniggering in the back there - it's well known; > see my signature) and run with DBDATE=Y4MD- and you don't, but it is > still, IMNSHO, worth always showing 4 digits for the years, and will > be for the next 7000 or so years (after which, you need to think about > showing 5 digits for the years). > Maybe in 7000 years we should start storing the year in Hex then people would now I was born in a BAD year :) Cheers Paul

Related threads