You need to sign in to do that
Don't have an account?
System.Exception {System.FormatException}
m_queryArray = oSFDCQuery.ExecuteQuery("select Support_Code__c, Name, CreatedByID, CreatedDate, Amount__c, Asset_Typ__c from Asset_Activity_Log__C where AccountID__c = '00130000005CZLD' ", oLogin);
With the "CreatedDate" in the query receive the following error...
"String was not recognized as a valid DateTime." as my inner exception
The Full Stack trace is as follows....
at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events)
at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle)
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
at SFDCLibrary.Sforce.SforceService.query(String queryString)
at SFDCLibrary.SFDCQuery.ExecuteQuery(String strQuery, cLogin oLogin)
at LicenceDetails.GetActivityLog() in s:\Projects\2005\AssetManager\LicenceDetails.aspx.cs:line 102
Now when i do not have "CreatedDate" everything works fine. And the query worked fine up until this morning when i made the following change. Thru SFDC setup i adjusted my custom object. I had field i changed from numeric(7,0) to a text field. I downloaded a new WSDL and deployed it.
Any ideas or suggestions to what i might have done wrong?
at LicenceDetails.GetActivityLog() in s:\Projects\2005\AssetManager\LicenceDetails.aspx.cs:line 102
That will help to see the error. Also, are you trapping for the SOAP exceptions or just system exceptions?
The lines of code in question are as follows...
--------------------------------------------------------------------------------------------------
100: ArrayList m_queryArray = new ArrayList();
101: m_queryArray = oSFDCQuery.ExecuteQuery("Select Amount__c, Asset_Typ__c, AssetActivityLog__c, CreatedById, CreatedDate, Name, Support_Code__c from Asset_Activity_Log__c where AccountID__c = '00130000004B546' ", oLogin);
102: if (m_queryArray.Count > 0)
---------------------------------------------------------------------------------------------------------------------------
The oSFDCQuery object and all of its methods are a custom SFDC wrapper we created to handle different function like internal auditing. As well as the app being able to preform different functions based on the oLogin object we pass in to the method. This specific method... ExecuteQuery is nothing special...
---------------------------------------------------------------------------------------------------------------------------
public ArrayList ExecuteQuery(String strQuery, cLogin oLogin)
{
try
{
//Build the Arraylist to hold results
ArrayList queryArray = new ArrayList();
//Set the query options
oLogin.Binding.QueryOptionsValue = new QueryOptions();
oLogin.Binding.QueryOptionsValue.batchSize = 10;
oLogin.Binding.QueryOptionsValue.batchSizeSpecified = true;
//Invoke the query call and save the result in a QueryResult
Sforce.QueryResult qr = oLogin.Binding.query(strQuery);
.....
---------------------------------------------------------------------------------------------------------------------
I personally see no reason why the query should be affected by having "CreatedDate" in or out.
Have you added a watch to the m_queryArray list after you run the ExecuteQuery (line 101) to see what it contains? Since you're not checking to see if the m_queryArray is null or not, it could be null and therefore throwing an error (though it wouldn't be a SOAP error, more invalid object call or something similar).
From what you've given me, thats about all I can see now. I would check the return object and make sure something is getting returned with valid return values. If your getting valid returned object and then getting an error on the .Count property call, I'm not sure what else it could be.
Huzzah!
Well the answer is and isn't in the code. So here is the issue. I am updating the custom Sales force object from my code, and pulling the information from my code. The "CreateDate" accepts a datetime fromat but!!!!!!!! you need to make sure it is not the standard datetime format you get from C# date object. It needs to be XML friendly. The call was being made to SFDC and the Date that was posted was poorly formated giving the XML error. I will post the correct DateTime format shortly as soon as i figure out what part of the C# date time format was breaking the XML.
Thanks For your help
--Joe
I'm looking forward to additional details.
Hi Joe,
Have you found the correct time format? I am having the same error, except htat I have never set the created date (is that even possible?). But I have set some other dates in my custom object and those dates look completely different in the returned XML, but that might because they are dates only and not date times:
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn: partner.soap.sforce.com" xmlns:sf="urn:sobject.partner.soap.sforce.com">
<soapenv:Body>
<queryResponse>
<result xsi:type="QueryResult">
<done>true</done>
<queryLocator xsi:nil="true"/>
<records xsi:type="sf:sObject">
<sf:type>License__c</sf:type>
<sf:Id>a0030000004yJAZbA2</sf:Id>
<sf:Id>a0030000004yJAZbA2</sf:Id>
<sf:CreatedById>00530000000tc3NAbQ</sf:CreatedById>
<sf:CreatedDate>2006-05-15T14:05:10.000Z</sf:CreatedDate>
<sf:LastModifiedById>00530000000tb3NAAQ</sf:LastModifiedById>
<sf:LastModifiedDate>2006-05-17T08:58:45.000Z</sf:LastModifiedDate>
<sf:License_Expiration__c>2200-01-01</sf:License_Expiration__c>
<sf:SU_Expiration__c>2200-01-01</sf:SU_Expiration__c>
....
The funny thing is that it works in SforceExplorer.
Update:
The inner exception stack trace:
[FormatException: String was not recognized as a valid DateTime.]
System.DateTimeParse.ParseExactMultiple(String s, String[] formats, DateTimeFormatInfo dtfi, DateTimeStyles style) +2283030
System.DateTime.ParseExact(String s, String[] formats, IFormatProvider provider, DateTimeStyles style) +46
System.Xml.XmlConvert.ToDateTime(String s, String[] formats) +26
System.Xml.Serialization.XmlCustomFormatter.ToDateTime(String value, String[] formats) +9
System.Xml.Serialization.XmlCustomFormatter.ToDate(String value) +11
System.Xml.Serialization.XmlSerializationReader.ToDate(String value) +5
Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderSforceService.Read37_NullableOfDateTime(Boolean checkType) +103
Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderSforceService.Read66_License__c(Boolean isNullable, Boolean checkType) +1711
Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderSforceService.Read111_sObject(Boolean isNullable, Boolean checkType) +2002
Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderSforceService.Read125_QueryResult(Boolean isNullable, Boolean checkType) +754
Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderSforceService.Read159_queryResponse() +285
Microsoft.Xml.Serialization.GeneratedAssembly.ArrayOfObjectSerializer57.Deserialize(XmlSerializationReader reader) +40
System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events) +163
I snooped around a bit in the DateTimeParse and I can see that it only throws that exact exception in that method if the input string date has length = 0.
-Jacob
Message Edited by Jake_ on 05-18-2006 01:46 AM
I am sending (privately) the query that reproduces the error to the SalesForce developers so they can investigate it at their convenience.
Message Edited by AngryBinary on 07-26-2006 12:49 PM
"The nice thing about standards is that there are so many to choose from"
Microsoft's parser contains a lot of date format strings, with different settings for different cultures like 'en-US', 'en-AU', 'fr-BE', and so on.
When I just checked a few moments ago, there are 14578 date format strings that the .Net 2.0 can handle across all cultures. They follow and include a bunch of different ISO, ANSI, RFC, and heaven-knows-who standard bodies.
Two of the format strings, ISO8601 (Microsoft calls it 'Universal') and RFC1132, are the ones we are interested in.
The Universal string complies with ISO 8601. Like so many other ISO standards, it is very complex and has a lot of options.
The W3C cites RFC1132 on Internet date and time formats, which pulls the definitions from RFC822, which in turn pulls in additional definitions from ANSI X3.51-1975. These give several different options as well.
Microsoft's parsers include several matching strings that follow both ISO 8501 and RFC822, including these two that closely match the SalesForce format:
SalesForce's generated date also follows both ISO 8501 and RFC822. It looks like this:
Even though both sides are using the same standards, they are using incompatable but legal variations within the standards.
I have tried to set new format strings by assigning my own conversion string for the thread. See System.Threading.Thread.CurrentThread.CurrentCulture.DateTimeFormat and GetAllDateTimePatterns() for more on doing that. A much more complex solution, but that allows more options to the rest of your program, is to add wrappers and/or extensions for the various SOAP classes that handle this conversion.
Since I assume that Microsoft won't change their format strings until .NET 3.0 (and maybe not even then), I believe it would just be easier if SalesForce used a different standard-compliant format.
I don't think its as simple as a blanket .NET 2.0 can't handle the T in the string, Hence the reason for asking about environments, for the people having the problem what exact version of .NET 2.0 are you using? If no-one logs a bug with MSFT with this, it'll never get fixed.
Message Edited by SimonF on 07-26-2006 04:39 PM
Message Edited by SimonF on 07-27-2006 11:07 AM
I lied. SalesForce doesn't use "yyyy-MM-ddTHH:mm:ssZ", but "yyyy-MM-ddTHH:mm:ss.000Z".
In any event, here is the work around I am using:
1. Modify your enterprise.wsdl file, change every occourance of "xsd:date" to "xsd:dateTime". That takes care of a conversion issue with the short dates.
2. Add this regular expression date changer to your SOAP envelope stream somewhere. That takes care of the extra .000Z.
void CopyAndStripDates( Stream from, Stream to ) {
TextReader reader = new StreamReader( from );
TextWriter writer = new StreamWriter( to );
writer.WriteLine( (new Regex( @"(>\d\d\d\d-\d\d-\d\dT\d\d:\d\d:\d\d).\d\d\dZ(</sf:)", RegexOptions.None )).Replace( reader.ReadToEnd(), "$1$2" ) );
writer.Flush();
}
-- NOTE: On previewing, it looks like the sequence :) is turned into a graphical smiley face instead of the two symbols : and )
Don't thank me for the work-around, just send money. :-)
If you're not too familiar with regular expressions, here is a brief explanation:
"(>\d\d\d\d-\d\d-\d\dT\d\d:\d\d:\d\d).\d\d\dZ(</sf:)"
Is just pattern matching for a bunch of digits, it looks like this fragment of the SOAP response:
>yyyy-MM-ddTHH:mm:ss.zzzZ</sf:
Each occourance is replaced with the pattern "$1$2" The two segments are the part between the parenthesis. The only stuff that isn't between section 1 and section two is the ".000Z" string that we want to omit.
If someone can get a capture of a response that causes the problem I'd like to see it.
Open a fresh new install of Visual Studio 2005. ( I happen to have reformated a test machine two days ago so it has one of those).
Run the app inside your debugger, putting in the session ID and sever url as specified. Watch as you get the exception.
I'd like to take you up on the WSDL / Sandbox offer, you can email me directly sfell at salesforce.com.
I sent the message and hopefully included enough to help with this. I have as 64.2 MB log file showing all the raw SOAP messages and socket communications for this tiny test app, but I assume you don't want to go through those.
I noticed before sending it this morning that the long date format didn't need to have the .000Z stripped off, whereas when I wrote the test snippit on Thursday afternoon it needed to be stripped off to prevent the exception. I'm wondering if the date parser is having an additional problem with afternoon times rather than morning times, but I don't really care to investigate more.
As I said, we do have a functional workaround for my organization with soap extensions. It doesn't fix the root cause, but I'm really not interested in debugging other people's code if I don't have to.
I hate "me-too" type of posts, but unfortunately I feel like I need to log this as well just so you guys (SF developers) are aware that this issue is seriously affecting your customers. For us, the unit tests would run just fine on local box, but on the build box (which kicks in with continuous integration) it just fails on the errors described by other posters. This is also intermitten - it has been working fine for weeks while in development and then all of a sudden the problem pops up today (with no code changes). This would explain why it has worked for you (Simon) while you were testing on your dev account (coincidentally, we are developing against a sandbox version like the other poster as well).
The whole situation now makes us very uncomfortable as we can't trust if it will reliably work on prod. I do believe .net 2.0 has something to do with it as our 1.1 version was just fine. Having said that, I personally think that you guys should at least try to find some workarounds rather than relying on fixes (if any) from MS.
Well, guess what ... it just starts working again (without the change you pointed out).
If I don't know better, I'd say you guys changed something on your end :)
So what we'd do is if we ever see that problem again, we'd put that config on and we see if that fixes it.
Thanks.
<system.xml.serialization>
<dateTimeSerialization mode="Local"/>
</system.xml.serialization>
in all our config files (heck, that caused us to change our code too as it changed all the date values).
Will keep you posted if we can find a fix.