SOAP/XML Error - InfoPath Dev
in

InfoPath Dev

SOAP/XML Error

Last post 05-10-2011 06:37 AM by Jimmy. 5 replies.
Page 1 of 1 (6 items)
Sort Posts: Previous Next
  • 05-26-2010 06:40 AM

    • cef424
    • Not Ranked
      Female
    • Joined on 05-17-2010
    • Windsor, CT
    • Posts 12

    SOAP/XML Error

    Ok, several things...

    1. Using InfoPath 2003 and while setting up my data connection for parameters on a repeating table it doesn't seem to keep them after I save?
    2. Then while I am trying to test the form I am getting this error:

      The SOAP response indicates that an error occurred: Server was unable to read request. ---> There is an error in XML document (1, 675). ---> Input string was not in a correct format.

    Carrie.

  • 05-27-2010 10:33 AM In reply to

    • cef424
    • Not Ranked
      Female
    • Joined on 05-17-2010
    • Windsor, CT
    • Posts 12

    Disregard... figured it out.

  • 05-06-2011 09:29 AM In reply to

    I'm seeing this same error. What did you do to resolve it for yourself?

  • 05-06-2011 10:51 PM In reply to

    This error could happen for a number of reasons.  What are the steps leading up to the error in your case?

    Jimmy Rishe / Software Developer / Microsoft MVP
    Qdabra Software
  • 05-09-2011 08:06 AM In reply to

    I've got a large infopath 2010 filler form (started with the generic blank form template) with about 250 fields, and I need to pull this data into a SQL Server table.  There are too many fields to pull the data into "published fields" in a sharepoint list then pull into SQL via access.  So, for my first time ever, I'm trying to submit the form to a web service, which then provides the fields as parameters to a stored procedure that does the table insert.

    I tried using the SQL Database form template, but I've got some varchar(max) fields in my table, and that template won't allow for submissions to sql db when varchar(max) fields are involved.

    With so many fields, they simply won't all be populated all the time, so null values are possible in the form data.  I saw a post from 2005 (http://kjellsj.blogspot.com/2005/04/submitting-xsiniltrue-values-from.html)  that indicated that with .NET 1.1 SOAP web services, you cannot have null values, and that post recommended writing custom code in the form, in the web service/stored procedure to put dummy data into any null-valued fields for the purpose of the web service submission then strip the dummy data out before it's written to the table.  I'm hoping to avod all that somehow.  I am unfamiliar with writing code to handle XML...

    I saw references to Qdabra's products, but I'm hoping to avoid the cost and complexities of involving additional products in the solution.

    If the null-value issue is really my problem, I'm surprised that there's not a simpler way of using web services to submit form data.  Seems like a big flaw in the solution, like using InfoPath is amazingly simple as long as you don't try sumitting to a webservice, which requires expertise in writing code to directly handle XML.

    Any help you can provide would be much appreciated.

  • 05-10-2011 06:37 AM In reply to

    The likely issue is that you are passing a blank value into a numeric or object parameter and this is causing the issue.  The options you have are:

    1. Pass the entire XML to the web service as a single parameter, and process it in the web service.
    2. Change all your parameter types to string, and handle them individually in the web service.
    3. Make sure that all of your fields have default values and validation to ensure they have the right type of data when they are submitted.

    At Qdabra, we're keenly aware of InfoPath's gaps, and we designed DBXL specifically to take the headache out of this very scenario.  You don't need to to write any code if you're using DBXL, and it will save you loads of time.  I strongly encourage giving it a try.

    Jimmy Rishe / Software Developer / Microsoft MVP
    Qdabra Software
Page 1 of 1 (6 items)
Copyright © 2003-2019 Qdabra Software. All rights reserved.
View our Terms of Use.