Question

Okay, I’m trying to get the String value of a DATE column in Oracle 11g to pass along to the UI in a C# app (via WCF). I want to display exactly what I’m pulling back in SQL Developer to a string variable in C#. Instead, when I’ve got a Date column, I’m getting some really wacky parsed DateTime values instead.

Examples:

Value in SQL Developer: 26-AUG-75
Value from myDataRow[0].ToString() in VS: 8/26/0975 12:00:00 AM

Value in SQL Developer: 01-JUL-76
Value from myDataRow[0].ToString() in VS: 7/1/1776 12:00:00 AM

The Oracle dates look right. VS’s don’t. Thanks, Ben Franklin and Edward the Martyr. What the heck?

The SQL’s pretty plain. I’m obviously changing field names, but this is it:

SELECT DISTINCT(MyDate) FROM
User1.TableOfDates@DateTableLink 
WHERE MyDate IS NOT NULL ORDER BY
MyDate

The shared code to throw SQL against the db is pretty plain as well. I’m going to censor it a good deal here, but it works well everywhere else so far, and I think I’ve got the important stuff here:

internal Oracle.DataAccess.Client.OracleConnection oracleConn;
...
DataTable dtReturn = new DataTable();
Oracle.DataAccess.Client.OracleCommand cmdTemp = null;
string strScrub = "";

// strScrub is magically loaded with SQL, which is, 
// if you grab it with a breakpoint here, after it's 
// scrubbed, equal to what I've written, above

cmdTemp = new Oracle.DataAccess.Client.OracleCommand(strScrub, this.oracleConn);
Oracle.DataAccess.Client.OracleDataReader dr = cmdTemp.ExecuteReader();
dtReturn.Load(dr);
dr.Dispose();
...
return dtReturn;

That part works. I only include it here in case there’s something from using Oracle.DataAccess that I should be aware of. Everything’s opened and closed and collected just fine. We’re throwing hundreds of commands through it each day in dev, and at least thousands on deploy.

Here’s some info from the immediate window for the first value (26-AUG-75), with dr now representing a single DataRow from the DataTable pulled from the code, above:

? DateTime.Parse(dr[0].ToString())
{8/26/0975 12:00:00 AM}
    Date: {8/26/0975 12:00:00 AM}
    Day: 26
    DayOfWeek: Saturday
    DayOfYear: 238
    Hour: 0
    Kind: Unspecified
    Millisecond: 0
    Minute: 0
    Month: 8
    Second: 0
    Ticks: 307569312000000000
    TimeOfDay: {00:00:00}
    Year: 975

And with just ? dr[0] — which gives the same thing:

?dr[0]
{8/26/0975 12:00:00 AM}
    Date: {8/26/0975 12:00:00 AM}
    Day: 26
    DayOfWeek: Saturday
    DayOfYear: 238
    Hour: 0
    Kind: Unspecified
    Millisecond: 0
    Minute: 0
    Month: 8
    Second: 0
    Ticks: 307569312000000000
    TimeOfDay: {00:00:00}
    Year: 975

Now interestingly that says it’s a DateTime when it’s just a Date in Oracle. Maybe I’m missing something about Oracle Dates…

? dr[0].GetType()
{Name = "DateTime" FullName = "System.DateTime"}

Anyhow, if I could get to the same value I see in SQL Developer (eg, 26-AUG-75), I’m fine. I can take that and do whatever I want.

Where is the implicit conversion going on, and how can I get in there a little earlier?

I should add that I can’t get creative with the SELECT statement & TO_CHAR. This is all a fairly complex automated process that builds queries based on user criteria. So changing this SELECT would be a “give a machine a fish” not “teach the machine to fish” answer. Any field could be a date in this format, so switching on GetType values and parsing some creative way in C# is fine, but changing the SQL isn’t.

EDIT Using a suggestion from here:

select dump(sysdate)today from dual; 

Using dump in the above SQL, run from SQL Developer, I get:
Typ=12 Len=7: 119,175,8,26,1,1,1 for 26-AUG-75’s row. So Oracle’s got the right date.

Following the conversion instructions found here…

119 - 100 "excess" = 19 centuries == 1900
175 - 100 "excess" = 75     years ==   75

That’s 1975.

Answer 1

It’s not clear from your question, but I assume you actually wanted 1975 and 1976?

I strongly suspect that the values 0975 and 1776 are actually what are in the database. Your values in SQL Developer are just a 2-digit-year representation of that. I suspect that if you perform a different kind of string conversion which uses a 4-digit-year representation, you’ll see the same values.

So, options after validating that the above is correct:

• Work out how the bad data got in the system, fix that (so you don’t get any more bad data) and then fix the existing data.
• Work around the issue by ignoring all but the last two digits of the year, and forcing them to an appropriate century. Note that there could be some “interesting” data around in terms of Feb 29th being valid in some years but not others…

I’d strongly suggest casting to DateTime rather than converting to a string and then parsing it, by the way.