resolution for datetime parsing issues with .NET 2.0

[SimonF]

There's been multiple threads on this, I've been working with the Microsoft folks to chase this one down. This is the feeback i got from them.

If a schema contains both “xsd:date” with nillable=true and “xsd:dateTime” with nillable=true, we will import either both as “date” or both as “dateTime”. In your case, both probably get imported as “date”, hence the time component cases a failure. This is a known bug and there is a hotfix available (KB 925272), available by calling PSS.

I tried out the hotfix on the failing test case i had and it addressed the issue, so if you're seeing this problem, you can either call Microsoft PSS and get the hotfix, or if you don't need access to any of the xsd:date fields, you can modify the wsdl by hand to remove these elements, and re-import it, and everything should be good.

[cdinh]

Hi,

I experienced this problem and applied the hotfix which solved the problem. However, it seems to have created another problem when I execute a query where non-string fields return their "specified" values as TRUE if its HasValue is also True.

These True values cause problems when I make changes to the object and update it as it will return error message such as "Unable to create/update fields: EndDate. Please check the security settings of this field and verify that it is read/write for your profile.

I assume in this case, it thinks I am trying to update EndDate because "EndDateSpecified = True" but EndDateSpecified was already True after the initial query.

I have removed the hotfix and can confirm that the problem no longer appears but then I get the original DateTime problem.

Has anyone else experienced this problem? Is this a problem with Salesforce or hotfix?

Thanks in advance,

cqdinh

[SimonF]

If the problem comes and goes with the addition/removal of the hotfix, then logically, the primary culprit would be the hotfix. I suggest you follow up with Microsoft PSS.

[beats]

Thank you Simon,  you are my hero.

I have been struggling with this issue for over a week. Initially, I thought it was related to globalization and date/time format because it was working on our local development server in Australia but not when we pushed it to production in the US.

Turns out it was probably related to the different versions of .NET we are running (we don't have a great deal of visibility to the production server).

I edited the WSDL to always use dateTime and works a charm!

Thanks,

Aaron

[Kunlun]

I meet same problem and I fix the hotfix but doesn't work either. Can you tell me how can I edit the WSDL to let it always use datetime?

Thanks

Kunlun

[JeffClark]

I am developing on Windows XP 64 bit version. VS defaults to 'any' processor when you create a new project. I've found that I had to change the Visual Studio project properties to compile to x86 only to fix this issue.

[Chris987654321]

I ran into this issue as well. The hotfix seems to talk about Windows Vista, but I am running on XP. Does that still apply?

I also tried commenting out this line from the WSDL 

 <!-- <enumeration value="xsd:date"/>-->

Is that correct?

Thank you,

Chris

Message Edited by Chris987654321 on 08-25-2009 02:28 PM

[sabamona · Accepted solution]

try replacing <enumeration value="xsd:date"/>  or  <enumeration value="xsd:dateTime"/> with  <enumeration value="xsd:string"/>.. it works for me :)

[acunha]

I just would like to confirm I was having the same issue here. I was trying to update a date field (custom field) using web services from C# .NET 2.0. It wasn't working and after changing the wsdl it works just fine.

Thanks a lot for the tip.