topic Re: Row.SetDate() throws exception in File Geodatabase API Questions

Row.SetDate() throws exception

JohnShiu — Tue, 06 Dec 2011 23:15:40 GMT

I've been utilizing the C# FileGDB API (VS2010) for one of our projects, and it appears that there may be an obscure bug involving the Row.SetDate() function.

For most of the dates in our dataset, the SetDate() function works fine. However, for one of the dates in our set (12/23/2008 12:00 AM), it throws a FileGDBException with error code -2147467259. Below is an example code snippet that will throw an exception on my machine. Here, "DATE" is an esriFieldTypeDate.

Row dateRow = table.CreateRowObject();
DateTime date = new DateTime(2008, 12, 23, 0, 0, 0, 0);
dateRow.SetDate("DATE", date);

In fact, if I try any dates in December 2008, (12/1/2008 through 12/31/2008) it will throw an exception. Dates in November 2008 and January 2009 work fine though.

Can anyone else replicate this issue? Or is this isolated to my setup?

Thanks for your assistance!
John

Re: Row.SetDate() throws exception

Leonvan_Daal — Fri, 16 Dec 2011 09:55:35 GMT

I'm seeing a similar issue. If I use SetDate() with a date, and then use the ArcCatalog tool to look at the contents of the database, I see that it has added one month to the stored date. So if I store the date 2002-01-04, the ArcCatalog shows that 2002-02-04 is stored. If I try to store 2002-01-29, it will throw the aforementioned exception. If it really adds one month, then it will try to store 2002-02-29, which is an invalid date. That would also explain why no date in December can be stored.

This looks like the inverse of the bug I found here:
http://forumsstg.arcgis.com/threads/39566-Date-fields-subtract-a-month-from-the-date-resulting-in-Exception

Best regards,

Leon

Re: Row.SetDate() throws exception

JohnShiu — Fri, 16 Dec 2011 12:45:56 GMT

Thanks very much for pointing that bug out, Leon. In the meantime, I've just removed the date fields which weren't essential for our dataset.

John

Re: Row.SetDate() throws exception

LanceShipman — Fri, 16 Dec 2011 15:29:36 GMT

The next release, sometime in the first half of 2012, includes a fix for this (NIM072876).