locked
InfoPath submitting to SharePoint list - some fields cause trouble RRS feed

  • Question

  • I have a large InfoPath Form which submits to a SharePoint list. For the most part it submits just fine.
    But a few of the fields on the form cause trouble. If I leave them out of the CAML and the submit code then it will add a new item to the SharePoint list just fine. But if I try to add one of these trouble fields then it no longer creates an item in the SharePoint list.

    What's worse, it seems to be silently erroring. There are no exceptions, the web service seems to have executed correctly...maybe there is some better way to check that I don't yet know?

    Here is the code I'm using to submit:

    public void FormEvents_Submit(object sender, SubmitEventArgs e)
    {
     bool Errored = false;
     try
     {
      XmlNamespaceManager ns = this.NamespaceManager;
    
      DataSource CamlDataSource = this.DataSources["XML File"];
      XPathNavigator CamlXPathNav = CamlDataSource.CreateNavigator();
    
      XPathNavigator MainXPathNav = this.CreateNavigator();
    
    
    
    
      // all the fields have some variation of this:
      string LastName = MainXPathNav.SelectSingleNode("/my:myFields/my:LastName", ns).Value;
      if (String.IsNullOrEmpty(LastName))
      {
       Errored = true;
      }
      CamlXPathNav.SelectSingleNode("/Batch/Method/Field[@Name='LastName']", ns).SetValue(LastName);
    
    
    
    
      CamlXPathNav.SelectSingleNode("/Batch/Method/@Cmd", ns).SetValue("New"); // Set the value of Cmd attribute to "New"
      if (Errored == false)
      {
       WebServiceConnection wsSubmit = (WebServiceConnection)this.DataConnections["Web Service Submit"];
       wsSubmit.Execute();
      }
     }
     catch (Exception ex)
     {
      Errored = true;
     }
    
     e.CancelableArgs.Cancel = Errored;
    }

     

    I'm using InfoPath 2007 and SharePoint Server 2007.

    Earlier I had the same issue where a column of the SharePoint list was holding a Date (only a Date, not time) but the field submitting to it held a Date & Time. It silently failed in the same way - and leaving that field out would cause a new item to not be added to the SharePoint list.

    But I've checked that. The three trouble fields are a dropdown list submitting text to a single-line-of-text, a checkbox submitting to a yes/no, and a date submitting to a date. The data types match on both ends.

    Thanks!

    • Edited by Chris Blume Thursday, July 7, 2011 7:34 PM Strange formatting made the text small.
    Thursday, July 7, 2011 7:25 PM

Answers

  • I presume an error is being returned by the web service but the execute method just isn't throwing an exception you can catch or returning a value. I haven't used it myself but the web service data connection has another overloaded execute method which takes XPathNavigator parameters for input, output and error. I'd guess that the output and error returned would give you the info you need.

    The execute method you are using is in effect showing success, because it was actually successful in executing the web service, if the web service runs into an error it will return that in it's return values, so you need to use an execute method that allows you access to those.

    More generally, adding the item will typically fail if the values provided don't match the fields to insert them into. The date format problem you ran into would be a common one, another would be text which is too long, or a number out of range. The other most common problem is getting the field names wrong, the internal field names often don't match field names displayed when you look at the list in the browser. You can see this easily if you use U2U's excellent CAML Query Builder tool (http://www.u2u.net/res/Tools/CamlQueryBuilder.aspx), quite often you'll see that when you select a field in it's interface, it shows a completely different name in the query itself. There's probably tools better suited to checking internal field names (maybe SharePoint Explorer?), but I always tend to have the CAML Query Builder close to hand so I just select the field I want to check and add it as a 'Order By' to the query, and the query text then shows it's internal name.

    • Marked as answer by Chris Blume Wednesday, July 13, 2011 8:20 PM
    Wednesday, July 13, 2011 9:19 AM

All replies

  • Perhaps a better, more direct question would be: What might cause the silent failure?


    wsSubmit.Execute(); does not throw. Does that mean the server had indicated the web service completed successfully?

    None of the CamlXPathNav.SelectSingleNode("/Batch/Method/Field[@Name='FieldNameHere']", ns).SetValue(SomeString); lines are throwing, so every value I set does indeed exist in the XML file. Does that also mean the value I'm setting has passed validation?

    Maybe I made a typo in both the code and the XML, but on SharePoint the field name is spelled correctly? That would mean the XPathNavigator::SelectSingleNode would succeed, as would the XPathNavigator::SetValue. Maybe that could cause a silent failure?

    What are potential causes for an item to:

    1. not be added to the SharePoint list, and
    2. doesn't involve any exceptions?

    Thanks!


    • Edited by Chris Blume Friday, July 8, 2011 1:22 PM Aahhh hahaha I typo'd the word "typo" :D
    Friday, July 8, 2011 1:00 PM
  • I presume an error is being returned by the web service but the execute method just isn't throwing an exception you can catch or returning a value. I haven't used it myself but the web service data connection has another overloaded execute method which takes XPathNavigator parameters for input, output and error. I'd guess that the output and error returned would give you the info you need.

    The execute method you are using is in effect showing success, because it was actually successful in executing the web service, if the web service runs into an error it will return that in it's return values, so you need to use an execute method that allows you access to those.

    More generally, adding the item will typically fail if the values provided don't match the fields to insert them into. The date format problem you ran into would be a common one, another would be text which is too long, or a number out of range. The other most common problem is getting the field names wrong, the internal field names often don't match field names displayed when you look at the list in the browser. You can see this easily if you use U2U's excellent CAML Query Builder tool (http://www.u2u.net/res/Tools/CamlQueryBuilder.aspx), quite often you'll see that when you select a field in it's interface, it shows a completely different name in the query itself. There's probably tools better suited to checking internal field names (maybe SharePoint Explorer?), but I always tend to have the CAML Query Builder close to hand so I just select the field I want to check and add it as a 'Order By' to the query, and the query text then shows it's internal name.

    • Marked as answer by Chris Blume Wednesday, July 13, 2011 8:20 PM
    Wednesday, July 13, 2011 9:19 AM
  • You, sir, are a golden god. For posterity:

    I changed the code to this:

    WebServiceConnection wsSubmit = (WebServiceConnection)this.DataConnections["Web Service Submit"];
    
    XmlDocument OutputDocument = new XmlDocument();
    XPathNavigator output = OutputDocument.CreateNavigator();
    XmlDocument ErrorDocument = new XmlDocument();
    XPathNavigator error = ErrorDocument.CreateNavigator();
    
    wsSubmit.Execute(null, output, error);
    

    And sure enough, the output XPathNavigator looked different on the erroring attempt. Strangely, the error XPathNavigator remained "". Anyway, this is what the output looked like:

    <UpdateListItemsResponse xmlns=\"http://schemas.microsoft.com/sharepoint/soap/\">
     <UpdateListItemsResult>
      <Results>
       <Result ID=\"1,New\">
        <ErrorCode>0x81020014</ErrorCode>
        <ErrorText>One or more field types are not installed properly. Go to the list settings page to delete these fields.</ErrorText>
       </Result>
      </Results>
     </UpdateListItemsResult>
    </UpdateListItemsResponse>
    

    Thanks again, Steven!

    Wednesday, July 13, 2011 8:23 PM