General

Re: Publish Failures After Migrating Forms into New Library

Jen B — Mon, 03 Mar 2014 19:26:21 GMT

Yes, I know 4000 is a lot - although MS Specs say it should be ok.

The why on the 424 fields is due to the form being used to support multiple teams who use the form to get their work and track it. All teams need to be on the same tool because, depending on the request, one or more teams may be working on the same request. We don't have the 424 fields all listed in any views.. .they get filtered and used as needed for each team to track their progress and then progress of the request.

The form has one main purpose - or two, depending upon how you look at it.. Our team (Learning & Development), use the tool to get requests from various operational areas. The requests are received by a triage-type team, then - depending on the request - assigned to at least one team (of 7 teams) who then use the tool to track their work. The triaging team and the departments then use the tool for status updates and reporting on work. Although you can look at it as two purposes (1. Get a request 2. Track the progress), the tracking of the status must be seen by all users. (Although not all 424 fields)

I have toyed with how to split, but the only option I see is splitting 1 form across 2-3 libraries to lessen the data needed in one sigular library. If you have other ideas, I'm open to them as no one has seemed to have other ideas on how to do it.

Everything on the form is OOTB. Buttons only query for data, change views or submit/save to the site. Since I made a copy of the form for the new library, I know the submit connections are fine as I tested them out prior to migrating the other forms over. I've verified the data connections work fine, but only have so many options to do that (i.e. checking via wizard and testing they work).

I can' t think of any external sources that can do any "grunt" work as you mention. I only connect to lists in Sharepoint for dropdown list options and have one connection to a SQL server for another group of dropdown list options I don't maintain.

Would love to get any insights from you on specifics to look for or thoughts on ways to "break up" the form.
Thanks,
jen

Re: Publish Failures After Migrating Forms into New Library

wilkies0106aw — Mon, 03 Mar 2014 17:05:00 GMT

4000 items in a SharePoint library is a lot.

I'm not sure how you or why you need to promote 424 fields to a SharePoint library, that seem very excessive. Even in a SharePoint view that would look horrific, and you'd run into issues, especially if you were using lots and lots of calculated columns.

Does the form have one or many purposes?

Can the form be split out in any way?

What is the form's purpose?

Does the form have links to external data sources, can the external sources do the 'grunt' work before you need to open a form?

If the form isn't publishing successfully, check your data connections, publishing and submit options.

Do any buttons on the form have code associated with them or is it all OOTB stuff? Is the form an Administrative template?

Publish Failures After Migrating Forms into New Library

Jen B — Mon, 03 Mar 2014 16:29:59 GMT

Greetings everyone,

I'm really hoping someone may have ideas on what is causing publishing errors. Background info: Infopath Filler form 2010 published to Sharepoint Enterprise 2007. No access to central admin for sharepoint and IT "doesn't have time" to troubleshoot. (i.e. If there's something to look for in central admin, I need specifics in order to get any help) Also, all verbose logging of errors is turned off.

We've had the filler form published to one library since March '13. Things worked well, until we started to hit 4000+ requests. I started to get content update failures when trying to publish. We increased our "archiving" and removal of requests to stay just under 4000 items, but that didn't help with the issue.

The form does promote 424 fields to sharepoint - which I do know now is a lot. Many people have informed me of this and we've actually come down from 500 fields... unfortunately, this form supports 10 teams who need reporting data so removing more is dicey. The removal of the 70+ fields was another attempt to find a resolution to the publish failure, but it did not help. Note it DID help in my stage environment - I was able to publish there - but production still fails.

I once got IT to increase time out settings, which helped, for about one month. Because we share the server we;re on with other sites, they refuse to make any further changes to these settings.

After removing the 70+ promoted fields failed to work in our prod library. I checked to see if a copy of the form would publish to another library; which it did. From that, we decided... ok, let's start fresh. So we worked this weekend to migrate to a new library (a long, long process). However, after moving the 3800 requests over to the new library, the form failed to publish sucessfully again. I removed 2000+ closed requests to see if that would make a difference, but to no avail.

The question is whether anyone has thoughts on why the form would publish easily up until the migration and even after we only had around 1500 forms in the library?

The form template itself is just under 1MB in size.

I feel like I've been banging my head against a wall for months now particularly without any support from our IT staff. ANY help would be appreciated!

Thanks,
Jen