TIMESTAMP data type?
Posted in 2000
Topics: Data Types & Schema Design, Platform-Specific Issues
I'm looking for this, which I'm told is an SQL-92 standard. However, my docs for IDS.2000 9.20.UC1 on RedHat linux 6.2 only allow DATETIME. Reading others' posts it's clear that TIMESTAMP isn't supported, and that I should use: DATETIME YEAR TO FRACTION(3) DEFAULT CURRENT or DATETIME YEAR TO FRACTION (5) Crap - this is the second example I've come across (the first was constraint naming) in which Informix is non-standard, but the other RDBMSs I've used (including SQL Server 7.0) *are* standard. Jeez - it's only been eight years; isn't that enough time to comply with the standard? For a "big" RDBMS like Informix, I thought they'd be *leading* the implementation of standards, not lagging so far behind in such basics as data types. Anyone from Informix want to comment? Because I have to CHANGE MY CODE! :-( matt
we use DEFAULT clause and it works well. But it is necessary to use this statement: DATETIME YEAR TO FRACTION(3) DEFAULT CURRENT YEAR TO FRACTION(3) flavio gattari Matthew Cornell ha scritto nel messaggio <3A1C4C89.B2B400ED@cs.umass.edu>... >I'm looking for this, which I'm told is an SQL-92 standard. However, my >docs for IDS.2000 9.20.UC1 on RedHat linux 6.2 only allow DATETIME. >Reading others' posts it's clear that TIMESTAMP isn't supported, and >that I should use: > >DATETIME YEAR TO FRACTION(3) DEFAULT CURRENT > >or > >DATETIME YEAR TO FRACTION (5) > >Crap - this is the second example I've come across (the first was >constraint naming) in which Informix is non-standard, but the other >RDBMSs I've used (including SQL Server 7.0) *are* standard. Jeez - it's >only been eight years; isn't that enough time to comply with the >standard? For a "big" RDBMS like Informix, I thought they'd be *leading* >the implementation of standards, not lagging so far behind in such >basics as data types. Anyone from Informix want to comment? Because I >have to CHANGE MY CODE! :-( > >matt