Read an Oracle TimeStamp using OCI stage
Moderators: chulett, rschirm, roy
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Timestamp(38) is assuming something else about the data - namely that it's Unicode encoded. What happens if you specify Timestamp(19)?
Last edited by ray.wurlod on Thu Nov 16, 2006 9:28 pm, edited 1 time in total.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Premium Member
- Posts: 1255
- Joined: Wed Feb 02, 2005 11:54 am
- Location: United States of America
Same story !
For 16th May 2000.
VarChar(19) reads it correctly as 16-MAY-00
Timestamp(19) reads it incorrectly as 3000-05-16 00:00:00
For 22nd May 2002.
VarChar(19) reads it correctly as 22-MAY-02
TimeStamp(19) reads it correctly as 2002-05-22 00:00:00
From what I observe, I think it is only the year 2000 is being read as 3000.
For 16th May 2000.
VarChar(19) reads it correctly as 16-MAY-00
Timestamp(19) reads it incorrectly as 3000-05-16 00:00:00
For 22nd May 2002.
VarChar(19) reads it correctly as 22-MAY-02
TimeStamp(19) reads it correctly as 2002-05-22 00:00:00
From what I observe, I think it is only the year 2000 is being read as 3000.
Anything that won't sell, I don't want to invent. Its sale is proof of utility, and utility is success.
Author: Thomas A. Edison 1847-1931, American Inventor, Entrepreneur, Founder of GE
Author: Thomas A. Edison 1847-1931, American Inventor, Entrepreneur, Founder of GE
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Well... this is different than the problem as originally stated:I_Server_Whale just wrote:From what I observe, I think it is only the year 2000 is being read as 3000.
This new set of data makes a little more sense... as Ray notes, something needs to be checked. There is a CENTURYPIVOT setting in the uvconfig file, but that's only in play when using IConv as far as I know. So I'm not really sure where this 'epoch setting' can be found. Can't seem to google up anything Oracle related.I_Server_Whale previously wrote:It is reading 26-APR-02 as 0002-04-26 00:00:00 instead of reading it as 2002-04-26 00:00:00.
![Confused :?](./images/smilies/icon_confused.gif)
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
I am pretty sure that the Oracle clients ARE backwards compatible. They are not, however, necessarily forwards compatible. Think about it - how can you write a client to access a database using features that weren't conceived at the time the client was written.
I do have one suggestion, however. Check the NLS settings on the client and the database. I haven't run into this in years (and never with DataStage), but this used to happen with 4-digit vs 2-digit year settings. I can't remember the full answer, but the client and the database need to be sync'd correctly. Usually they are by default, but someone could have switched a setting. And of course, you are looking at the client on the machine running DataStage.
I do have one suggestion, however. Check the NLS settings on the client and the database. I haven't run into this in years (and never with DataStage), but this used to happen with 4-digit vs 2-digit year settings. I can't remember the full answer, but the client and the database need to be sync'd correctly. Usually they are by default, but someone could have switched a setting. And of course, you are looking at the client on the machine running DataStage.
I know what you are saying and agree with it in principal. However, I've never had a problem accessing a higher version database with a lower version client that I recall, whereas I have had issues going the other way. By sticking with a 'lowest common denominator' approach to the client software, you ensure that any features you leverage are applicable to both database versions. Going the other way you really can't say the same thing.jdulaney wrote:I am pretty sure that the Oracle clients ARE backwards compatible. They are not, however, necessarily forwards compatible. Think about it - how can you write a client to access a database using features that weren't conceived at the time the client was written.
I'll have to present this to my DBAs tomorrow, see if they have any words of wisdom on the subject.
![Wink :wink:](./images/smilies/icon_wink.gif)
Thanks for the reminder - it is controlled by the NLS_DATE_FORMATsetting in the database. It is typically set to DD-MON-RR to solve this 'Y2K' issue but may have been set to a 'YY' year mask in yours. Check with your DBAs, hopefully it's something simple like that.
Here is an article from DBMS Magazine in 1998 discussing the issue... or at least one very much like it.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
-
- Premium Member
- Posts: 1255
- Joined: Wed Feb 02, 2005 11:54 am
- Location: United States of America
How do I check the NLS settings?jdulaney wrote:I do have one suggestion, however. Check the NLS settings on the client and the database.
Just to save some time
![Smile :)](./images/smilies/icon_smile.gif)
Thanks a lot !
Whale.
Anything that won't sell, I don't want to invent. Its sale is proof of utility, and utility is success.
Author: Thomas A. Edison 1847-1931, American Inventor, Entrepreneur, Founder of GE
Author: Thomas A. Edison 1847-1931, American Inventor, Entrepreneur, Founder of GE