Hi - this is my 1st post and I hope someone can help with a problem I have.

From Sharepoint, I took the list option to "Customize Form". I then customized the form in infopath 2010 and tried to publish but it comes up with the error:

"The publish operation could not be completed. It cannot be determined if the form template was successfully published. Try publishing the form template again, or change the list settings to use the default sharepoint form. The SOAP message cannot be passed."

I've also tried just taking the "Customize form" option from sharepoint and making no changes in infopath and then publishing and still I get the same error. I've also tried removing all but one field on the form but that doesn't work either. I then created a new test list on the same site with a few columns and tried creating a form for that list and that published fine so there is clearly something up with the list I'm trying to design the form for.

Any ideas please as I'm totally stuck for ideas for this.

You've narrowed it down to that list, so you need to figure out what it is about that list that's causing.  There's nothing about the error that tells us anything, so unless you go find the full error details in the ULS logs, we'll just be guessing. 

ULS Logs - is that something I can view as an end user or would the Sharepoint administrator need to check that?  I have design rights on the site I have access to, but not direct access to the Sharepoint server.

I've gone through pretty much every detail of the list to try and figure out what may be different but without any success.  I guess the cause is deeply hidden.

I tried looking at the event logs on my PC but they weren't much help.

Yeah, the ULS logs require access to the SharePoint server (the web front end that handled your request).  Though InfoPath is a great tool for end users, it truly requires architectural knowledge and skill to ensure it works perfectly when using InfoPath Forms Services (list forms use this).

Hi

I'm afraid the ULS log information below means nothing to me,  but I'm hoping that it will help to identify the problem.  I've pasted the last section of the log from when the error happened:

RE tp_ListId = 'F5C66FBF-CF4B-4A1B-B7F5-B1D78A743768' AND tp_ID = 3756 AND tp_Version=9 AND tp_Level=1 AND tp_RowOrdinal=0;UPDATE UserDataVersioned SET sql_variant7=N'98 / PS / ' WHERE tp_ListId = 'F5C66FBF-CF4B-4A1B-B7F5-B1D78A743768' AND tp_ID = 3757 AND tp_Version=9 AND tp_Level=1 AND tp_RowOrdinal=0;UPDATE UserDataVersioned SET sql_variant7=N'89 / PS / ' WHERE tp_ListId = 'F5C66FBF-CF4B-4A1B-B7F5-B1D78A743768' AND tp_ID = 3759 AND tp_Version=7 AND tp_Level=1 AND tp_RowOrdinal=0;UPDATE UserDataVersioned SET sql_variant7=N'83 / PS / ' WHERE tp_ListId = 'F5C66FBF-CF4B-4A1B-B7F5-B1D78A743768' AND tp_ID = 3761 AND tp_Version=3 AND tp_Level=1 AND tp_RowOrdinal=0;UPDATE UserDataVersioned SET sql_variant7=N'90 / PS / ' WHERE tp_ListId = 'F5C66FBF-CF4B-4A1B-B7F5-B1D78A743768' AND tp_ID = 3762 AND tp_Version=7 AND tp_Level=1 AND tp_RowOrdinal=0;UPDATE UserDataVersioned SET sql_variant7=N'90 / PS / ' WHERE tp_ListId = 'F5C66FBF-CF4B-4A1B-B7F5-B1D78A743768' AND tp_ID = 3763 AND tp_Version=4 AND tp_Level=1 AND tp_RowOrdinal=0;UPDATE UserDataVersioned SET sql_variant7=N'71 / PS / ' WHERE tp_ListId = 'F5C66FBF-CF4B-4A1B-B7F5-B1D78A743768' AND tp_ID = 3764 AND tp_Version=19 AND tp_Level=1 AND tp_RowOrdinal=0;UPDATE UserDataVersioned SET sql_variant7=N'71 / PS / ' WHERE tp_ListId = 'F5C66FBF-CF4B-4A1B-B7F5-B1D78A743768' AND tp_ID = 3765 AND tp_Version=16 AND tp_Level=1 AND tp_RowOrdinal=0;UPDATE UserDataVersioned SET sql_variant7=N'70 / PS / ' WHERE tp_ListId = 'F5C66FBF-CF4B-4A1B-B7F5-B1D78A743768' AND tp_ID = 3766 AND tp_Version=9 AND tp_Level=1 AND tp_RowOrdinal=0;UPDATE UserDataVersioned SET sql_variant7=N'50 / PS / ' WHERE tp_ListId = 'F5C66FBF-CF4B-4A1B-B7F5-B1D78A743768' AND tp_ID = 3772 AND tp_Version=8 AND tp_Level=1 AND tp_RowOrdinal=0;UPDATE UserDataVersioned SET sql_variant7=N'28 / PS / ' WHERE tp_ListId = 'F5C66FBF-CF4B-4A1B-B7F5-B1D78A743768' AND tp_ID = 3780 AND tp_Version=9 AND tp_Level=1 AND tp_RowOrdinal=0;UPDATE UserDataVersioned SET sql_variant7=N'28 / PS / ' WHERE tp_ListId = 'F5C66FBF-CF4B-4A1B-B7F5-B1D78A743768' AND tp_ID = 3781 AND tp_Version=11 AND tp_Level=1 AND tp_RowOrdinal=0;UPDATE UserDataVersioned SET sql_variant7=N'22 / PS / ' WHERE tp_ListId = 'F5C66FBF-CF4B-4A1B-B7F5-B1D78A743768' AND tp_ID = 3782 AND tp_Version=9 AND tp_Level=1 AND tp_RowOrdinal=0;UPDATE UserDataVersioned SET sql_variant7=N'015 / Trn / ' WHERE tp_ListId = 'F5C66FBF-CF4B-4A1B-B7F5-B1D78A743768' AND tp_ID = 3783 AND tp_Version=20 AND tp_Level=1 AND tp_RowOrdinal=0;UPDATE UserDataVersioned SET sql_variant7=N'15 / PS / ' WHERE tp_ListId = 'F5C66FBF-CF4B-4A1B-B7F5-B1D78A743768' AND tp_ID = 3784 AND tp_Version=19 AND tp_Level=1 AND tp_RowOrdinal=0;UPDATE UserDataVersioned SET sql_variant7=N'2 / PS / ' WHERE tp_ListId = 'F5C66FBF-CF4B-4A1B-B7F5-B1D78A743768' AND tp_ID = 3787 AND tp_Version=9 AND tp_Level=1 AND tp_RowOrdinal=0;UPDATE UserDataVersioned SET sql_variant7=N'2 / PS / ' WHERE tp_ListId = 'F5C66FBF-CF4B-4A1B-B7F5-B1D78A743768' AND tp_ID = 3788 AND tp_Version=8 AND tp_Level=1 AND tp_RowOrdinal=0;UPDATE UserDataVersioned SET sql_variant7=N'TBC / PS / ' WHERE tp_ListId = 'F5C66FBF-CF4B-4A1B-B7F5-B1D78A743768' AND tp_ID = 3790 AND tp_Version=11 AND tp_Level=1 AND tp_RowOrdinal=0;UPDATE UserDataVersioned SET sql_variant7=N'TBC / PS / ' WHERE tp_ListId = 'F5C66FBF-CF4B-4A1B-B7F5-B1D78A743768' AND tp_ID = 3791 AND tp_Version=10 AND tp_Level=1 AND tp_RowOrdinal=0;UPDATE UserDataVersioned SET sql_variant7=N'0 / PS / ' WHERE tp_ListId = 'F5C66FBF-CF4B-4A1B-B7F5-B1D78A743768' AND tp_ID = 3792 AND tp_Version=13 AND tp_Level=1 AND tp_RowOrdinal=0;UPDATE UserDataVersioned SET sql_variant7=N'0 / PS / ' WHERE tp_ListId = 'F5C66FBF-CF4B-4A1B-B7F5-B1D78A743768' AND tp_ID = 3796 AND tp_Version=29 AND tp_Level=1 AND tp_RowOrdinal=0;UPDATE UserDataVersioned SET sql_variant7=N'58429 / Dev / ' WHERE tp_ListId = 'F5C66FBF-CF4B-4A1B-B7F5-B1D78A743768' AND tp_ID = 3799 AND tp_Version=5 AND tp_Level=1 AND tp_RowOrdinal=0;UPDATE UserDataVersioned SET sql_variant7=N'58419 / PS / ' WHERE tp_ListId = 'F5C66FBF-CF4B-4A1B-B7F5-B1D78A743768' AND tp_ID = 3800 AND tp_Version=9 AND tp_Level=1 AND tp_RowOrdinal=0;UPDATE UserDataVersioned SET sql_variant7=N'58179 / Dev / ' WHERE tp_ListId = 'F5C66FBF-CF4B-4A1B-B7F5-B1D78A743768' AND tp_ID = 3807 AND tp_Version=7 AND tp_Level=1 AND tp_RowOrdinal=0;UPDATE UserDataVersioned SET sql_variant7=N'58178 / Dev / ' WHERE tp_ListId = 'F5C66FBF-CF4B-4A1B-B7F5-B1D78A743768' AND tp_ID = 3808 AND tp_Version=4 AND tp_Level=1 AND tp_RowOrdinal=0;UPDATE UserDataVersioned SET sql_variant7=N'58512 / Lic / ' WHERE tp_ListId = 'F5C66FBF-CF4B-4A1B-B7F5-B1D78A743768' AND tp_ID = 3812 AND tp_Version=5 AND tp_Level=1 AND tp_RowOrdinal=0;UPDATE UserDataVersioned SET sql_variant7=N'58492 / Lic / ' WHERE tp_ListId = 'F5C66FBF-CF4B-4A1B-B7F5-B1D78A743768' AND tp_ID = 3816 AND tp_Version=20 AND tp_Level=1 AND tp_RowOrdinal=0;UPDATE UserDataVersioned SET sql_variant7=N'58483 / Lic / ' WHERE tp_ListId = 'F5C66FBF-CF4B-4A1B-B7F5-B1D78A743768' AND tp_ID = 3817 AND tp_Version=5 AND tp_Level=1 AND tp_RowOrdinal=0;UPDATE UserDataVersioned SET sql_variant7=N'58442 / Lic / ' WHERE tp_ListId = 'F5C66FBF-CF4B-4A1B-B7F5-B1D78A743768' AND tp_ID = 3821 AND tp_Version=4 AND tp_Level=1 AND tp_RowOrdinal=0;UPDATE UserDataVersione'     CommandType: Text CommandTimeout: 0 3fcc87e8-8f0e-407b-a403-ebd5e0f9bbb7

04/18/2011 13:25:52.97 w3wp.exe (0x0238) 0x12C4 SharePoint Foundation Database btq8 High System.Threading.ThreadAbortException: Thread was being aborted.     at SNIReadSync(SNI_Conn* , SNI_Packet** , Int32 )     at SNINativeMethodWrapper.SNIReadSync(SafeHandle pConn, IntPtr& packet, Int32 timeout)     at System.Data.SqlClient.TdsParserStateObject.ReadSni(DbAsyncResult asyncResult, TdsParserStateObject stateObj)     at System.Data.SqlClient.TdsParserStateObject.ReadNetworkPacket()     at System.Data.SqlClient.TdsParserStateObject.ReadBuffer()     at System.Data.SqlClient.TdsParserStateObject.ReadByte()     at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)     at System.Data.SqlClient.SqlDataReader.ConsumeMetaData()     at System.Data.SqlClient.SqlDataReader.get_MetaData()     at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)     at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)     at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)     at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)     at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)     at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior)     at Microsoft.SharePoint.Utilities.SqlSession.ExecuteReader(SqlCommand command, CommandBehavior behavior, SqlQueryData monitoringData, Boolean retryForDeadLock)     at Microsoft.SharePoint.SPSqlClient.ExecuteQueryInternal(Boolean retryfordeadlock)     at Microsoft.SharePoint.SPSqlClient.ExecuteQuery(Boolean retryfordeadlock) 3fcc87e8-8f0e-407b-a403-ebd5e0f9bbb7

04/18/2011 13:25:52.97 w3wp.exe (0x0238) 0x12C4 SharePoint Foundation General 8e2s Medium Unknown SPRequest error occurred. More information: 0x80131530 3fcc87e8-8f0e-407b-a403-ebd5e0f9bbb7

04/18/2011 13:25:52.97 w3wp.exe (0x0238) 0x12C4 SharePoint Foundation Logging Correlation Data xmnv Medium Site=/sites/nfp 3fcc87e8-8f0e-407b-a403-ebd5e0f9bbb7

04/18/2011 13:25:52.98 w3wp.exe (0x0238) 0x12C4 SharePoint Foundation General 72nz Medium Videntityinfo::isFreshToken reported failure. 3fcc87e8-8f0e-407b-a403-ebd5e0f9bbb7

04/18/2011 13:25:52.98 w3wp.exe (0x0238) 0x12C4 SharePoint Foundation Monitoring b4ly High Leaving Monitored Scope (Request (POST:http://gateway:80/sites/nfp/ps/pmo/projects/_vti_bin/FormsServices.asmx)). Execution Time=121823.1919 3fcc87e8-8f0e-407b-a403-ebd5e0f9bbb7

04/18/2011 13:25:53.01 w3wp.exe (0x0238) 0x12C4 SharePoint Foundation Logging Correlation Data xmnv Medium Name=Request (GET:http://gateway:80/sites/nfp/ps/pmo/projects/_layouts/error.aspx?ErrorText=Request%20timed%20out%2E) edd963de-a016-49d1-9400-f3d5aaf489a5

04/18/2011 13:25:53.01 w3wp.exe (0x0238) 0x12C4 SharePoint Foundation Logging Correlation Data xmnv Medium Site=/sites/nfp edd963de-a016-49d1-9400-f3d5aaf489a5

04/18/2011 13:25:53.03 w3wp.exe (0x0238) 0x12C4 SharePoint Foundation Monitoring b4ly Medium Leaving Monitored Scope (Request (GET:http://gateway:80/sites/nfp/ps/pmo/projects/_layouts/error.aspx?ErrorText=Request%20timed%20out%2E)). Execution Time=10.147 edd963de-a016-49d1-9400-f3d5aaf489a5

Yeah, you usually get something useful - I have no idea what the huge block of jibberish is at the top, though.  The only thing I can possibly extract from that is that you're hitting a timeout.  InfoPath does have some built-in timeouts for data connection queries.  Is your form paused for a while before getting the SOAP error?

In the block of text at the top, there are Sharepoint ID's so it suggests it's working it's way through the records.

It pauses for 2 mins before the error is displayed.

 

Another observation - creating a copy of the list via the template function with a limited set of data and the form works fine.  Copy across more data and then it errors, so that would now suggest a data problem.

How you then track down the offending data I have no idea in amongst thousands of records.  Is there a way to trap this?  The ULS log doesn't seem to offer much.

Through trial and error, I've now determined it is due to a timeout.  On our test list, If I delete a load of records, I can get the form to publish.  If I then restore the records it will error again.  I've tried this with different combinations of records to prove that it's a timeout rather than a data issue and I'm pretty confident this is now the problem.

Can anyone advise please what setting should be changed though so the form publishing does not timeout?

Thanks

 

Any thoughts please on which timeout value needs to be increased to stop the form publishing from timing out? Thanks

Can anyone confirm if when submitting a form, Infopath validates all the data and could timeout if it takes longer than whatever timeouts have been set?

Also, what timeouts should be change to prevent this happening.

Thanks

From a Sharepoint 2010 list, I open up the form using the infopath link.  

This opens the form for editing.  Without making any changes at this point, I take the quick publish option.  Infopath sits there for a couple of minutes before displaying: soap error - message cannot be parsed and the form is not published.  There is no specific indication of what the problem might be.

After many google searches and questions on forums over several weeks, it seems this problem cannot be resolved.

How can this be called "Quick Publish"?  It's really frustrating.

• Merged by Clayton Cobb Sunday, June 19, 2011 4:31 PM Tried to sneak in the same thread topic two months later

Try to publish the form in the ordinary way, not the quick publish, make sure you are not adding any extra query strings or any thing to the URL of the site name, or the place of the library where to store the form, don't include the view name in the URL for the library name, or the forms folder. They may be OK in this publish process but may do issues later as this issue. Try it and let us know.

It has worked instantly for every list I've ever converted.  So, you have something wrong with your environment and need to find out what it is.  There should be entries in the ULS logs or Application Event viewer each time this happens.

Mohamed, list forms can only use Quick Publish, because they can only be published back to the list where they are bound.

I was thinking he was using form libraries (My fault). In this case I can't think of anything can go wrong.

That's great that its worked for every list ever converted.  I would have preferred that.  This is the first time I've  tried and it's failed on the the 1st attempt.

I've posted the ULS logs previously on this forum, but that doesn't seem to have helped much.

Surely "quick publish" shouldn't be flawed with the user having to delve into environment settings - then it's not really quick.  Or, there should be an alternative to quick publish that gives a better insight into why it didn't work - like a debug mode.

 

That's the point.  It DOES work in normal situations and has worked in every farm I've ever built.  There is no special configuration to make it work, and no other publish type is needed.  You aren't having to delve into the ULS logs due to Quick Publish, but rather due to an inconsistency or issue with your environment.  You can't blame the product before you've confirmed your environment is in a healthy state.

This has nothing to do with Quick Publish.  Checking the ULS logs is how SharePoint works - it is a standard for figuring out issues.  It's up to you whether you will actually go try to figure it out or just take pot shots at something that may not even be the product's f

The point is, I can't figure it out and so look to advice from forums for helpful advice.

I am an end user of an Office 2010 tool - Infopath hoping to publish my form using quick publish.  I am not an IT technician who configures the environment that this is used in, so if the tool does not work and gives very little indication of why it's not working, then I use Google and forums to gain additional advice to help solve the problem.

 

This is not an Office 2010 tool.  It is a very advanced SharePoint Server 2010 Enterprise tool.  This feature only exists in the most expensive and most complex version of SharePoint ever created.  The Office side of it is only one small part of it.  The big part is InfoPath Forms Services, which is where the problem lies, not in the Quick Publish feature.

Therefore, you need to work with your SharePoint architect and/or farm administrator to determine why the farm is not working.  No tool can give you the exact answer to the problem in every scenario with a perfect error message.  Even if you were able to find the issue based off that very generic error message, you probably would not have access to the farm or server to fix it.  This is why the first step should always be to submit the trouble ticket to whoever runs the farm if you are not the person who runs it. 

Unfortunately then I may never get this resolved as our IT dept that supports sharepoint are also at a loss.  Admittedly, Sharepoint is a new environment for them so their knowledge is limited but I was hoping for a few pointers.

What's strange is that if I take a copy of the list and delete most of the records then the form will publish.  That would suggest the environment is OK.  If I try and publish the form from the copied list with all records in place (about 2000 records) then it errors.  I wouldn't think 2000 records is excessive though.

You didn't mention that they had already tried figuring it out nor that it works depending on the # of items in the list.  All of that is critical info that we needed initially.  Perhaps you just recently tested the copied list, but knowing that your farm is run by people who don't know SharePoint 2010 is very important info.

I'm not sure how there is a SharePoint 2010 Enterprise farm implemented by people with limited SharePoint knowledge, but they should at least have looked at the logs, and the ULS logs surely show the error details of what is going on.  That would be the absolute first place they would look, and that is the information you need in order to have some direction on what to fix/resolve.  It can't just be resolved on the front-end.  From the very beginning, you were complaining about the Quick Publish when that is not the source of the problem.  We need to focus frustration and attention on the actual problem, and we can't know what it is without details such as the ones you just gave and the contents of the error in the ULS logs.

2000 is definitely not excessive, but there may be something about the fields in the list that is causing it.  Why are you just now converting to InfoPath when the list already has 2000 items.  What other back story details can you give us?  I can create a dummy list with 2000+ items and see if I can reproduce the behavior, but I'd probably need to know more about the list and its columns (lookup columns by chance?).

The list was created and was used for sometime.  Then I discovered the input form could be much improved using Infopath and so the form was then designed, but could not publish.  For me, Sharepoint is a tool to assist with my day job (which isn't being a sharepoint professional) and so I am learning as I go.  Probably not the perfect way, but no doubt probably the most frequent way software tools are used.  Having said that, I am pretty adept and can pick up software pretty quickly but this is probably the first time I have drawn a complete blank.

I have posted the ULS logs previously that you have looked at.  My previous post is here, but as replies had dried up, i tried posting again:

http://social.technet.microsoft.com/Forums/en-US/sharepoint2010customization/thread/ea8da113-fe9a-4878-9994-c1f24cc85c37

In the test list, I deleted a load of data until such time as it would publish.  Then I removed that data and put the originally removed data back, so still working on a reduced list and it published again.  That confirmed there wasn't a problem with the data content, but potentially the volume of it, which like I said dosen't seem that large.

Any help greatly appreciated.

Come on, man, that just wasted a whole lot of my time (and that of others probably).  You never make a 2nd thread on the same topic, especially when there is no new info.  I had to go 12 replies deep into this thread to get you to tell me you already posted a thread on it.

Those ULS logs do not show a specific error.  Did you get them yourself?  There would have to be something much more specific related to the exact point in time when your error occurred.

Merging now.

I posted 5 replies on the other thread but with no response, so that's why I started a new thread.  Different people passing through might see it and be able to offer some helpful advice.

I worked with the IT dept to get the ULS logs and they made sure they captured the details at the exact point in time so they should be relevant.

Hi,

we are now dealing with this issue with MS support guys. It has definitely something to do with data volume. SharePoint tries to update every record in the list when you Publish InfoPath form. It is known issue. You are not first one who is facing the same problem.

I will post the result.

 

 

Thanks for the update Tomas.  It's good to hear it's a known issue and I'm not on my own.  I'll be interested to hear the results.

 

I've been searching for a resolution to this issue for 2 weeks now. I have 2 lists with the same symptoms on different servers. One requires modification so i'll have to cut off access, copy all the data, modify the form and after... copy back the data.

I'm looking forward for a solution to this problem.

There could be several factors causing this, but one case I have also seen is the amount of columns you have in your list. Also the amount of list items. Infopath does everything though web services, and I bet if you run Fiddler while you Quick Publish the form you will see a Request Timed Out error.

You can get around this by upping SharePoint's timeout (default is 2 minutes) to something larger to get the form to publish. Here is how - http://weblogs.asp.net/jeffwids/archive/2010/09/04/how-to-increase-the-timeout-for-a-sharepoint-2010-website.aspx

This should allow you to get the form published, but you need to figure out what it is that is causing it to take so long. I had a list with 70 columns and that was the issue.

• Proposed as answer by C1pendule Friday, July 22, 2011 5:11 AM

Thanks Ryan

That's some useful advice.  I will try that out.

You're right about the timeout Ryan.  This is what Fiddler shows:

 

#	Result	Protocol	Host	URL	Body	Caching	Content-Type	Process	Comments	Custom
14	200	HTTPS	gateway.****.co.uk	/sites/nfp/ps/pmo/projects/_layouts/error.aspx?ErrorText=Request%20timed%20out%2E	7,002	private	text/html; charset=utf-8	infopath:6380

 

I presume now the timeout change you've suggested should resolve this.  I can't try just yet as I need to get the site administrator to do this.

Hi,

as Ryan wrote, increased request timeout value (<httpRuntime maxRequestLength="51200" executionTimeout="300" />) solves the problem. It is also recommended workaround from the MS guys. You have to fine tune timeout value on production environment or increase the value only temporarily. Necessary value is dependent on the size of the list and the number of columns.

In a large list, it takes the SharePoint to much time to update all records (list items) in the database. This is by design.

 

Tomas

• Proposed as answer by Tomas Chytil Friday, July 08, 2011 12:23 PM

So earlier postings said their was no special configuration to make it work, but the MS guys say there is - interesting.

Thanks Ryan and Tomas for the update.  Our admin guy returns from vacation on Monday so I look forward to trying this out.

 

Unfortunately what Chytil proposed isn't working for me. It still shows the SOAP message error even with the executionTimeout=3600.

It's definitely a column/line number problem that times out the service. My form started with this error after 3500 lines. Now i have 8500. I've copied the data in a empty list with a modified form but i lost the created and modified column.

Maybe there is a normal solution...

 

I haven't had the changes made yet to test but I was timing mine though and it times out after about 2 mins, 5 sec.  Does yours run for longer before the SOAP error. 

Mine runs for exactly the same as yours (powderblue) 2minutes and 5 sec. Does this mean that the changes i made ware not applied or just plain wrong.

It was a mistake i made. I set the executionTimeout not on <system.web>. After i correctly set the Timeout to 300 it seems to be working.

Thanks everyone.

Hi Guys,

I know this is pretty late but I have managed to pinpoint this problem, maybe MS can tell us why. I have been working straight two days on this issue where I couldn't publish my infoPath forms and I followed all your advices here but with no luck.

I then tried to track back and I switched off a SharePoint Feature I had written in VS 2010 from the site collection level and I tried it again and boom it worked. So I don't know if this is the same situation as the rest of you but what I picked up is that since I activated my feature the system could not allow me to publish my infoPath forms anymore in order to get around doing this for now I have to switch off the custom feature and publish my form and switch it back on and it works fine.

If any of you have experienced this please let me know. I will working on trying to find out why this happens.

Thank you

Regards

Bhuti

• Marked as answer by Margriet BruggemanMVP Friday, April 06, 2012 1:04 PM

I've been dealing with this same issue for months and have spent countless hours with MS support, who has decided it's just the # of items in the list that's the issue.

Weeks later, while working on a workaround solution, I've discovered the issue has something to with calculated columns (probably in combination with the # of items). One of my lists that has been getting the error has around 15k items. I created a new list using a template of the first with a copy of most of the existing data. Coincidentally, I also deleted the calculated columns in the new list, as I no longer needed them for my purposes. After doing this I realized that I needed to remove them from the form template as well, but at this point I assumed deleting the columns from the list was moot, because I wouldn't be able to edit the form anyway, but I thought I'd give it a shot, just for the heck of it.... So I clicked Quick Publish and within a matter of seconds - SUCCESS.

So I did some more testing with other lists that have been getting the error by deleting calculated columns and publishing the forms. Successful on all attempts. It also seems that the # of items has no effect as long as there are no calculated columns in the list.

Although it's inconvenient that you have to remove the very useful calculated columns to get this to work, this should hopefully subdue a great deal of everyone's frustration with this issue.

• Proposed as answer by MichaelPip Friday, June 07, 2013 1:18 PM

I get the same problem for a list with 13000 items and 18 calculated columns. The SQL CPU is at 100% percent instantly after I click the Quick Publish. I don't believe it's related to timeout, but to some SQL issue. This is so irritating!

Changes to the timeout settings did not solve the problem for me.

This is so frustrating.  I have a lot of calculated columns but it is impractical for me to remove these.

Any other suggestions or a fix from Microsoft would be appreciated.

I have the same problem.  I have a list - with only say about 100 entries, only a few calculcated columns, about 25 columns total and am seeing this problem immediately after I deleted some columns in the list (which were not on the custom form and weren't needed).

I tried everything including deleting the calculcated fields, deleting various fields form the form - deleting everything in the form except the required title field... no luck.

I templated the list - recreated it - same issue.  I'm stuck with re-creating the entire list and starting from scratch and wasting about 1 week of time in the form customization work at this point.

 

To add something -

I'm having this problem on a simple list - with no calc'ed columns, only one item in the list, about 25 columns, and only one required column (title) -

I get the error within a few seconds so I don't think it's a timeout issue but I'll talk to my server guy and adjust the timeout if possible - this sure sounds like a fundamental bug somewhere in forms services.

Not to argue with the previous MVP poster, but snappy comments about "don't blame the product" aren't helpful.  

Does anyone have any further ideas for this problem?  It is still not possible for me to publish an Infopath form and the 'user experience' using the standard form is not great.  An Infopath form would make data entry so much clearer.

Use a Windows based InfoPath form rather than web based  Its just an idea a. will it work b. its a work around

Make sure the <system.web> xml tag in your web.config in C:\inetpub\wwwroot\wss\VirtualDirectories\spwebappname has both maxrequestLength and executionTimeout attributes, to overcome the timeout issue the executionTimeout attribute must exist and in this example is set to 300 seconds or 5 minutes.

<location path="_layouts/UploadEx.aspx">
    <system.web>
      <httpRuntime maxRequestLength="51200" executionTimeout="300" />
    </system.web>
  </location>

This above post is correct for SharePoint Foundation 2010 in SharePoint Server 2010 the same entry at least in our web.config occurred in a different location or twice and the attribute for executiontimeout had to be manually added with the value of 300 secs

Make sure the <system.web> xml tag in your web.config in C:\inetpub\wwwroot\wss\VirtualDirectories\spwebappname has both maxrequestLength and executionTimeout attributes, to overcome the timeout issue the executionTimeout attribute must exist and in this example is set to 300 seconds or 5 minutes.

<location path="_layouts/UploadEx.aspx">
<system.web>
<httpRuntime maxRequestLength="51200" executionTimeout="300" />
</system.web>
</location>

Hi Bhuti,

I had the same problem and finding solution from last three days. Thanks to you, your solution has resolved my problem.

Thanks,

Rakesh

Not sure if this post is still of interest to anyone, but today I experienced the same problem and used this post as guidance on finding a solution.  I successfully managed to overcome the problem by changing the web.config settings.  I tried a timeout at specified by Jason as follows:

<system.web>
      <httpRuntime maxRequestLength="51200" executionTimeout="300" />
</system.web>

This didn't work and after 5-mins it still timed out.  I then changed the executionTimeout to 600 (i.e. 10-mins) which subsequently worked.  I reckon the publish task ran for 6 to 7 minutes before completing.  I'd sort of proved the point it was record volume related by saving my list as a template (no content) and then perfroming the same task on a new test list build from the template with no records - worked immediately without the executionTimeout property.

Anyway, my two-pennies worth is that it's all going to be down to record-volume and complexity of table.  Fortunately my table, although complex with lots of calculated fields, only had (approx) 4000 records.  I reckon if I'd had 10,000, I'd need to allow for a timeout of around 1050 (17.5 minutes).

Hope this helps someone as it looks like this issue has been around for a while!  Can't for the life of me understand why volume of records should affect form publish - but hey-ho sure Microsoft know!

Cheers, Scott

• Proposed as answer by Scott Hews Wednesday, November 14, 2012 11:57 AM

Complexity of the table yes record volume No.

• Proposed as answer by Jason Robertson Tuesday, November 20, 2012 9:44 PM

Complexity of the table yes as fields are added the xml schema for the lists Form becomes bigger. I have tested this scenario by adding and removing records forn the list it made no difference. The origianl post was about submitting  (publishing a Form).

Just to say that this worked for me, I have several calculated columns and removed the latest one I had which fixed the issue.

I don't know if the reason was that this column perhaps had a #VALUE in some cases or it was just too many calculated columns within the list however

Thank you Jason, I ran into this error again and this time it was not caused by a feature but many records in a list that have many columns as well.

So now we know that two issues that can cause the soap error are timeout and a custom feature.

I increased my timeout to 600 and at 6 minutes my form was successfully published. After the publish I took it back to 300 but it's good to know how to resolve this error hen it happens.

Regards

Bhuti

Hi Guys,

I know this is pretty late but I have managed to pinpoint this problem, maybe MS can tell us why. I have been working straight two days on this issue where I couldn't publish my infoPath forms and I followed all your advices here but with no luck.

I then tried to track back and I switched off a SharePoint Feature I had written in VS 2010 from the site collection level and I tried it again and boom it worked. So I don't know if this is the same situation as the rest of you but what I picked up is that since I activated my feature the system could not allow me to publish my infoPath forms anymore in order to get around doing this for now I have to switch off the custom feature and publish my form and switch it back on and it works fine.

If any of you have experienced this please let me know. I will working on trying to find out why this happens.

Thank you

Regards

Bhuti

This worked for me after a lot of trial & error... thanks!

HI Jason,

I run out on the same problem today and using your step i managed to come out from the problem.

Thanks saved my time.

Regards,

Sabby