Getting data back to InfoPath browser form after submit action - InfoPath Dev

InfoPath Dev

Use our Google Custom Search for best site search results.

Getting data back to InfoPath browser form after submit action

Last post 07-23-2010 05:22 AM by lestomos. 2 replies.
Page 1 of 1 (3 items)
Sort Posts: Previous Next
  • 07-16-2010 12:31 AM

    Getting data back to InfoPath browser form after submit action


    I am developing an IP form which sends data to a web service that, in turn, calls stored procedures in an SQL-Server. This web service has only two methods that handle Submit and Receive IP actions, respectively. The IP submit data connections perform insert, update and delete queries, and the receive data connections just retrieve data, that is, they just carry out select queries. At the moment, I am trying to retrieve error messages from the database and display them on the InfoPaht client, in a TextField.

    So far, I have been creating IP rules with submit data and receive data connections. Si I first submit parameter to my web service, wich in turn calls a stored procedure (insert, update or delete) on my database. Subsequently, if an error occurs in the stored procedure, it is stored in the database. The second action of this rule, the receive data connection, looks up an error message from the database, which is then displayed by the InfoPath Client. It works like so:

    INFOPATH CLIENT   - - - - - - - - - - - - - - - - - - - - - - - - - - - -> WEB SERVICE - - - - - - - - - - - - - - - - - - - - - - - - - - -> SQL SERVER


      Action 1: Submit Data                                                  Method SendData() called                                                 stored procedure called (insert, update or delete). If error occurs, save it into table Errors  [1st SERVER ROUND-TRIP]

     Action 2: Receive Data (error message)                   Method GetData() called                                                    stored procedure called (select error message by id)  [2nd SERVER ROUND-TRIP]

    The two actions from the InfoPath client entail two server round-trips - one to call an insert, update or delete query and another to eventally retrieve errors that might have occured while inserting, updating or deleting data, and send them to the InfoPath client. For performance reasons, I would like to store, update or delete data in my database and eventually getting back an error message with just one server round-trip. My question is:

    Is it possible to get any data back to the InfoPath client after performing a Submit Data action with just one server round trip or I will always have to add a Receive Data action in my rules to retrieve possible error messages?

    Thanks in advance,


  • 07-22-2010 12:11 AM In reply to

    Re: Getting data back to InfoPath browser form after submit action

    Hi Lestomos,

    Have you considered submitting data using a Receive Data connection? You could write code that gets data from a Submit Data Connection too, but it might be simpler to do the Receive route. Otherwise, what you are doing makes sense. Do you really have a performance issue or is it just a performance paranoia? We do double submit and queries all the time without much in the way of a perf penalty.

    Happy trails,

    Patrick Halstead
    Project Manager at Qdabra
  • 07-23-2010 05:22 AM In reply to

    Re: Getting data back to InfoPath browser form after submit action

     Thanks for your reply, Patrick.

    I have finally found the solution to my problem and would like to share it with future users who search for a solution in this forum:

    1. I have added TRY-CATCH blocks to my stored procedures.

    2. In the catch-blocks I have raised an error and passed error_message as parameter and added some text to it.

    3.  In the web service I have added TRY-CATCH blocks, so that when an exception from the database is raised the web service sends my custom error messages to the InfoPath client.

    Thanks a lot, Patrick,


Page 1 of 1 (3 items)
Copyright © 2003-2019 Qdabra Software. All rights reserved.
View our Terms of Use.