none
limit of 75 <SharePoint:Formfield on a dataformwebpart?

    Question

  • Hi,

    I've got some data views that I brought over from sharepoint 2007 via a database attach.  they don't render in internet explorer; you simply get the generic:

    Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Microsoft SharePoint Foundation-compatible HTML editor such as Microsoft SharePoint Designer. If the problem persists, contact your Web server administrator.



    Correlation ID:

    If I bring the number of fields down to around 75(sorry, have tried to count several times but I keep getting interrupted) or less it works; add too many and you get the message...

    the question is, is this part of a throttle?  Logs indicate there is a stack overflow.

    Best regards,

    S'

    Tuesday, May 11, 2010 2:07 PM

Answers

  • Here is the posted work around that Microsoft Premier Support gave us. Please mark this as resolved as this is the documented fix from me calling support.

    Custom List Form in SharePoint Designer 2010 will not render if the list has a large number of columns.

    Symptom

    Custom List Form will not render if the list has a large number of columns. To reproduce this issue create a custom list and add 68 single line of text columns. The custom list form web part will not render and an error message such as this will occur in the browser:

    Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Microsoft SharePoint Foundation-compatible HTML editor such as Microsoft SharePoint Designer. If the problem persists, contact your Web server administrator.

    Correlation ID:

    For more information about custom list forms please refer to this article:

    http://office.microsoft.com/en-us/sharepoint-designer-help/create-a-custom-list-form-using-sharepoint-designer-HA010378258.aspx

    Cause

    This occurs when a large XSL transforms happens in a single template.

    Resolution

    The issue can be resolved by breaking up the offending xsl template into smaller parts to avoid a large transform.

    This example is for a New Form custom list form. The Edit Form is similar in template naming convention. Please refer to the end of the article for the template names of the various form modes.

    1. Open the page that contains the none working custom list form web part.
    2. Switch to code for this this workaround.
    3. Search for the following string:

    <xsl:call-template name="dvt_1.rowedit"/>

    4. Copy this line paste it 3 to 5 times. The table structure and other components that makeup this template will be divided into the other copied templates. A general guideline is to have about 20 to 40 table rows per template. There is a fair amount of give with this recommendation.

    5. Rename each pasted template by adding a number to the end of it.

    <xsl:call-template name="dvt_1.rowedit"/>
    <xsl:call-template name="dvt_1.rowedit2"/>
    <xsl:call-template name="dvt_1.rowedit3"/>
    <xsl:call-template name="dvt_1.rowedit4"/>
    <xsl:call-template name="dvt_1.rowedit5"/>

    6. Now, press the control key and click the dvt_1.rowedit. This will highlight the template's first line which is this:

    <xsl:template name="dvt_1.rowedit">

    7. Place the cursor infront of the less than sigh of <xsl:template name="dvt_1.rowedit">
    8. Hold down Control + Shift and then press semicolon. This will highlight the entire template.
    9. Go to the bottom of the template. The following should be the last line:

    </xsl:template>

    9. Paste the following markup after the closing xsl temlate tag from stpe 9. In this example there are 5 different dvt_1.rowedit templates calls so we'll need 5 <xsl:template> elements to match.

    <xsl:template name="dvt_1.rowedit">
    <xsl:param name="Pos" select="position()"/>
    <tr>
    <td>
    <table border="0" cellspacing="0" width="100%">

    </table>
    </td>
    </tr>
    </xsl:template>

    10. Rename each of the templates pasted in step 9 to match the templates from step 5.

    <xsl:template name="dvt_1.rowedit">

    <xsl:template name="dvt_1.rowedit2">

    11. Next, the conents of <xsl:template name="dvt_1.rowedit"> needs to be divided among the new templates, <xsl:template name="dvt_1.rowedit2">, <xsl:template name="dvt_1.rowedit3"> and so forth. The easiest way to do this is to start at the end of the template and cut out the last few table rows and paste them into the last template that was created. In this example that would be <xsl:template name="dvt_1.rowedit5">

    The individual table rows that represent the various SharePoint fields are stored inside of the table HTML element and that valid HTML needs to be persisted into the new templates. A good way of ensure this happens is to find <table border="0" cellspacing="0" width="100%"> in <xsl:template name="dvt_1.rowedit"> and perform a Control + Shift + Semicolon to highlight the entire table.

    Once this is done scroll down to the end of the table and carefully take entire table rows, <tr>, and their contents over to the last xsl template.

    By default the following is the last chunk of markup in <xsl:template name="dvt_1.rowedit">:

    <tr id="idAttachmentsRow">
    <td nowrap="true" valign="top" class="ms-formlabel" width="20%">
    <SharePoint:FieldLabel ControlMode="New" FieldName="Attachments" runat="server"/>
    </td>
    <td valign="top" class="ms-formbody" width="80%">
    <SharePoint:FormField runat="server" id="AttachmentsField" ControlMode="New" FieldName="Attachments" __designer:bind="{ddwrt:DataBind('i','AttachmentsField','Value','ValueChanged','ID',ddwrt:EscapeDelims(string(@ID)),'@Attachments')}"/>
    <script>
    var elm = document.getElementById(&quot;idAttachmentsTable&quot;);
    if (elm == null || elm.rows.length == 0)
    document.getElementById(&quot;idAttachmentsRow&quot;).style.display=&apos;none&apos;;
    </script>
    </td>
    </tr>
    <xsl:if test="$dvt_1_automode = '1'" ddwrt:cf_ignore="1">
    <tr>
    <td colspan="99" class="ms-vb">
    <span ddwrt:amkeyfield="ID" ddwrt:amkeyvalue="ddwrt:EscapeDelims(string(@ID))" ddwrt:ammode="view"></span>
    </td>
    </tr>
    </xsl:if>

    This particular table row represents the attachment functionality inside of a custom list form. This should not be in multiple templates and makes sense to go to the last XSL template created.

    All the other table rows, <tr>, should contain the various columns in your list. Again, start from the bottom and work up to keep this exercise easy.

    Adjust these steps accordingly if custom HTML layout is used to display field controls.

    12. Finally, here is an example of the finished product. Each template only contains 1 column and the attachment functionality in the last xsl template. Also, only <xsl:template name="dvt_1.rowedit"> and <xsl:template name="dvt_1.rowedit2"> were included.

    <xsl:template name="dvt_1.rowedit">
    <xsl:param name="Pos" select="position()"/>
    <tr>
    <td>
    <table border="0" cellspacing="0" width="100%">
    <tr>
    <td width="190px" valign="top" class="ms-formlabel">
    <H3 class="ms-standardheader">
    <nobr>Title<span class="ms-formvalidation"> *</span>
    </nobr>
    </H3>
    </td>
    <td width="400px" valign="top" class="ms-formbody">
    <SharePoint:FormField runat="server" id="ff1{$Pos}" ControlMode="New" FieldName="Title" __designer:bind="{ddwrt:DataBind('i',concat('ff1',$Pos),'Value','ValueChanged','ID',ddwrt:EscapeDelims(string(@ID)),'@Title')}"/>
    <SharePoint:FieldDescription runat="server" id="ff1description{$Pos}" FieldName="Title" ControlMode="New"/>
    </td>
    </tr>
    </table>
    </td>
    </tr>
    </xsl:template>

    <xsl:template name="dvt_1.rowedit5">
    <xsl:param name="Pos" select="position()"/>
    <tr>
    <td>
    <table border="0" cellspacing="0" width="100%">
    <tr>
    <td width="190px" valign="top" class="ms-formlabel">
    <H3 class="ms-standardheader">
    <nobr>NewColumn90</nobr>
    </H3>
    </td>
    <td width="400px" valign="top" class="ms-formbody">
    <SharePoint:FormField runat="server" id="ff91{$Pos}" ControlMode="New" FieldName="NewColumn90" __designer:bind="{ddwrt:DataBind('i',concat('ff91',$Pos),'Value','ValueChanged','ID',ddwrt:EscapeDelims(string(@ID)),'@NewColumn90')}"/>
    <SharePoint:FieldDescription runat="server" id="ff91description{$Pos}" FieldName="NewColumn90" ControlMode="New"/>
    </td>
    </tr>
    <tr id="idAttachmentsRow">
    <td nowrap="true" valign="top" class="ms-formlabel" width="20%">
    <SharePoint:FieldLabel ControlMode="New" FieldName="Attachments" runat="server"/>
    </td>
    <td valign="top" class="ms-formbody" width="80%">
    <SharePoint:FormField runat="server" id="AttachmentsField" ControlMode="New" FieldName="Attachments" __designer:bind="{ddwrt:DataBind('i','AttachmentsField','Value','ValueChanged','ID',ddwrt:EscapeDelims(string(@ID)),'@Attachments')}"/>
    <script>
    var elm = document.getElementById(&quot;idAttachmentsTable&quot;);
    if (elm == null || elm.rows.length == 0)
    document.getElementById(&quot;idAttachmentsRow&quot;).style.display=&apos;none&apos;;
    </script>
    </td>
    </tr>
    <xsl:if test="$dvt_1_automode = '1'" ddwrt:cf_ignore="1">
    <tr>
    <td colspan="99" class="ms-vb">
    <span ddwrt:amkeyfield="ID" ddwrt:amkeyvalue="ddwrt:EscapeDelims(string(@ID))" ddwrt:ammode="view"></span>
    </td>
    </tr>
    </xsl:if>
    </table>
    </td>
    </tr>
    </xsl:template>


    Supplemental Information

    The following are the template names for Edit Forms and Display Forms. The same concept applies to these as the New Form templates.

    Display Form:

    <xsl:call-template name="dvt_1.rowview"/> and <xsl:template name="dvt_1.rowview">

    Edit Form, which is the same as New Form:

    <xsl:call-template name="dvt_1.rowedit"/> and <xsl:template name="dvt_1.rowedit">


    Linda Chapman | SharePoint Consultant | My Blog: http://LindaChapman.BlogSpot.com | http://www.linkedin.com/in/LindaChapman
    • Proposed as answer by Fidy13 Monday, June 06, 2011 11:47 AM
    • Marked as answer by swirch Thursday, June 09, 2011 2:42 PM
    Sunday, April 10, 2011 9:39 PM

All replies

  • Not sure exactly which limit you are hitting but 75 fields is a lot.  There's a max row size of 8,000 bytes per row.  For more info on the boundaries you might want to check out:

    http://download.microsoft.com/download/1/7/5/175B2219-F5BF-4004-B416-558ED60811A6/SPServer2010CapacityBoundariesLimits.docx


    John
    SharePoint911: SharePoint Consulting
    Blog: http://www.rossonmoss.com
    Twitter: JohnRossJr

    MOSS Explained: An Information Workers Deep Dive into Microsoft Office SharePoint Server 2007
    Tuesday, May 11, 2010 3:07 PM
  • Hi John,

    Thanks for the reply!  just read through the document...don't see this one, but I'm filing a copy for future reference...very useful.

    I'm not certain if I'm running into a database retrieval problem, or a problem with the webpart rendering the data.  It's related to input fields (<SharePoint:FormField) so I suspect it's the web part.  On the other hand I'm not familiar with the locking mechanisms in sharepoint so it may be the database retrieval.

    What I'm doing is simply creating a custom EditForm.aspx.  I insert a data view; by default spd inserts all of the columns in the list.  spd renders the form just fine, but if you open it in internet explorer(or firefox) you get the above error.

    If you remove some columns bringing it under around 75 it displays fine in the browser. Keep adding columns till it breaks again...remove a column it works, add a column (any seems to do it) and it breaks again.

    I've tried rendering in 2007 mode (default for an attached database), and enabling the preview in 2010 mode.

    I've turned on the developers dashboard; no errors there, but a lot more details in the log files...

    75 fields on a form?  ah, no.  I need several hundred.  This page in it's entirety has a dozen web parts calling half a dozen lists; it's around 500Kbytes.  most of the web parts display fine...<xsl:value-of doesn't seem to be impacted, but <SharePoint:FormField is.

    Best Regards,

    S'

    Tuesday, May 11, 2010 3:34 PM
  • Just to be clear I'm not talking about the number of fields on the form -- but 75+ fields in a DVWP is a lot.  I wouldn't recommend showing all of those fields in the DVWP or any view.

     Not really sure exactly what you are trying to accomplish but can you edit the form in InfoPath?  Then just use the DVWP to display a smaller number of fields?  Perhaps I'm misunderstanding what you are trying to do -- if so could you clarify what you are trying to do with the DVWP in relation to the form?


    John
    SharePoint911: SharePoint Consulting
    Blog: http://www.rossonmoss.com
    Twitter: JohnRossJr

    MOSS Explained: An Information Workers Deep Dive into Microsoft Office SharePoint Server 2007
    Tuesday, May 11, 2010 4:18 PM
  • Hi John,

    I've built a business application in sharepoint...sort of like the templates microsoft distributed for help desk, sales lead, etc.

    To accomplish this i created a series of custom lists, each of which has a newform.aspx, editform.aspx, and dispform.aspx.  I use sharepoint designer to customize those forms.  the listformwebpart works ok; it displays and enables editing of all of the fields in the list, which has around 150 columns in it.

    If I simply create a new edit list form for the list, spd creats a new form, inserting the list view web part (open the all files object, right-click and choose make a new page from existing). Then hide the list view, insert a web part zone and insert a data view in the web part zone.

    Alternatively open lists and libraries, navigate to the list, open the dashboard for it, then make a new edit form, which puts the dataform web part immediately on the page.  

    Both are a single item view.

    Best regards,

    S'

     

    Tuesday, May 11, 2010 5:41 PM
  • Let me clarify --

    You have created a custom list in SharePoint 2010 that has about 150 columns in it.

    You've used SPD 2010 to edit the forms for the list -- so you made the changes to the form in InfoPath 2010 and then published them back.

    DispForm.aspx is basically just a form with an XSLT List View Web Part which is how views are displayed.  My advice for this would be to break the data into separate views so you aren't trying to display all of that information at the same time.  It is perfectly fine to have so many fields in your list but from a usability perspective I'd imagine you've got an extremely lengthy horizontal scroll to fit so many columns on the screen at one time.

    You might technically be able to figure out how to do it -- but usability is important too. My suggestion would be to use separate views with less fields which would definitely work.


    John
    SharePoint911: SharePoint Consulting
    Blog: http://www.rossonmoss.com
    Twitter: JohnRossJr

    MOSS Explained: An Information Workers Deep Dive into Microsoft Office SharePoint Server 2007
    Tuesday, May 11, 2010 6:10 PM
  • Hi John,

    Yes to the first, custom list.

    No to the infopath; trying to follow a thin client here...office isn't installed on the clients.  this is one of the reasons i want sp 2010 so bad, i want to web host office.  trying to stay ahead of the curve here; i want users to be able to render and work with these pages on iPhones, iPod touches, iPads and other diskless devices.  we invest way too much time applying windows patches here and are looking at reducing it expenditure tremendously with this architecture.

    for the breaking of the data view...i'd be having the user file half the data at a time...would really rather not.  workflows fire on data changes and it would add to the complexity.

    Note this web page is not just a long list of fields...i'm using tables and everything html, javascript and xsl can give me to present an attractive form.  contractable/expandable panes, tabs, etc.  if you've ever used a system like salesforce you'll know this is not unusual in a business application, pretty normal actually. 

    anyways, making some progress.  read an article about moss 2007 having a limit of 200 controls on a page.  apparently this is set in the web.config file.  really prefer not to goof around with that tho.

    ran an experiment where on my test form i was maxed out, getting the error.  i went through the xsl code and removed several of the <sharepoint:fielddescription controls...crossed my fingers and success!!! i was able to slide a few more fields on the page.

    So, i'm going back to my production forms and removing the <sharepoint:fielddescription controls...don't use them anyways.

    I checked on the document you refered to on your first post on the limits...don't see any mention of changes to the number of controls on a page (I think it's actually on a web part since i have many web parts on this page and the others are working fine.  i compared my web.config files on the moss 2007 and sp 2010 servers, both have a reference <safemode maxcontrols="200".  don't see anything else remotely like this, but since i need more fields on the webparts i'll be doing a little more digging in this direction.  Anyone else have any clues here?  Desparately seeking more technical documentation on sharepoint 2010...

    Best regards,

    S'

    Tuesday, May 11, 2010 6:48 PM
  • I'm just a little confused here -- are you using SharePoint 2010?  If the answer is yes, then all your list forms are already InfoPath 2010. 
    John
    SharePoint911: SharePoint Consulting
    Blog: http://www.rossonmoss.com
    Twitter: JohnRossJr

    MOSS Explained: An Information Workers Deep Dive into Microsoft Office SharePoint Server 2007
    Tuesday, May 11, 2010 7:24 PM
  • Um, yea, 2010.  have only used infopath once to trial under 2007...once i saw each client needed it installed i walked away.

    my criteria for a client is that it have a browser...I don't really want to go through the effort of getting all the clients updated with office, and then patching...omg.  and getting approval to roll office 2010 across the client base?  right.

    tryed jacking the maxcontrols up to 1000...tried an issreset, no impact.  just finished restarting the server for kicks and grins, still no impact.

    Tuesday, May 11, 2010 7:32 PM
  • When you click on a list to create a new item -- the window that pops up is an InfoPath form.  You don't need the InfoPath client to view it -- all of the forms are web enabled.  If you were to open the list with SPD 2010 you'll see a button to edit the form in InfoPath.  It is quite easy.


    John
    SharePoint911: SharePoint Consulting
    Blog: http://www.rossonmoss.com
    Twitter: JohnRossJr

    MOSS Explained: An Information Workers Deep Dive into Microsoft Office SharePoint Server 2007
    Tuesday, May 11, 2010 7:36 PM
  • What would editing in infopath do for me?  can you add more controls there?
    Tuesday, May 11, 2010 8:01 PM
  • This all just seems overly complex.  The changes to the form should be very simplistic to make in InfoPath 2010.  Then you should be able to create other views from SPD 2010 -- which BTW all views in SP2010 are all essentially DVWPs.  My suggestion is to create separate views to eliminate the need for one gigantic view that shows everything.

    Just my opinion -- simplify the view to show less and I think it solves your technical problem and makes the view easier to use.  You can still export information from the list if you needed to do a more complex sort or filter on the entire dataset. 


    John
    SharePoint911: SharePoint Consulting
    Blog: http://www.rossonmoss.com
    Twitter: JohnRossJr

    MOSS Explained: An Information Workers Deep Dive into Microsoft Office SharePoint Server 2007
    Tuesday, May 11, 2010 8:45 PM
  • John,

    If I could throw out 950 of the 1,000+ fields on this page I would.  This is one of many web parts on a page with tabs, collapsible/expandable regions and other tricks to make a user friendly application.  All of the other pages and workflows are working.

    Do you have any contacts at microsoft that could possibly shed some light on this problem?  Our software licensing person is out on maternity leave so I can't seem to get regular support for this, and there seems to be no technical documentation on the hobbled data view web part in sharepoint 2010.  I've been googling this for some time.

    My only other alternative seems to be to use the new xsl list view web part which seems to require adopting the 2010 look and feel which will require me to re-brand the sharepoint portal.  I'm not sure if this will work...have barely used the xsl list view web part, and there may be a lot of forms i have to convert.  unfortunately there doesn't seem to be a converter available so I'd be trying to copy and past the html, xsl and javascript onto the new views.

    It's beginning to look as if this is the show-stopper to upgrading to sharepoint 2010.  Still can't beleive the dataview web part has been axed.  this was always brought forward as the holy grail of web parts, and it's been phased out.

    Best regards,

    Steve

     

    Wednesday, May 12, 2010 2:13 AM
  • The data view web part has not been "axed" -- you can still add it the same way you always could.  Can still attach to various data sources like web services, RSS Feeds, etc. The XSLT List View Web Part is basically the same thing, it's just more flexible.  In fact all list views are now XSLT List View Web Parts.  If you haven't looked, take a look at your site in SPD 2010.  You'll see the DVWP, you'll see that XSLT List Views are the same, and you'll see how easily you can edit the List Forms with InfoPath.

    I'm still a little confused -- in your last message you mention that it would "require adopting the 2010 look and feel" -- does that mean that you are running in Visual Upgrade?

    It sounds like there's a lot of information you are trying to display on the page at one time.  The out of the box mechanisms might not be the best option in this case.  Have you considered writing some sort of code to display the data in a different way? 

     


    John
    SharePoint911: SharePoint Consulting
    Blog: http://www.rossonmoss.com
    Twitter: JohnRossJr

    MOSS Explained: An Information Workers Deep Dive into Microsoft Office SharePoint Server 2007
    Wednesday, May 12, 2010 2:35 AM
  • Hi John,

    As usual you ask a lot of reflective quesitons :)

    When I say axed...I'm reading that a compatible data view web part was added to sharepoint 2010 to support the rollover to the xsl list view web part.  It's apparently not the same in the respect to how many fields can be input.  and we better be prepared to move away from it.  This is my root problem, it's not fully compatible; it restricts how many inputs you can use.

    While I have brought the site to the 2010 look and feel (preview mode) no, I'm not adopting the new look and feel as I didn't adopt the 2007 look and feel.  I tend to replace the toolbars and menus as most programmers do.  the canned ones are too limiting and are very inflexible.

    As many people are I work for a large corporation where gods lay down the rules.  Mine are that I use sharepoint designer to it's fullest potential.  Visual studio is restricted to workflows only.  If I had a choice I'd be doing this all in visual studio; I suspect I'd be having fewer problems.

    Best,

    S'

    Wednesday, May 12, 2010 2:55 AM
  • Unfortunately, I don't have a good answer for you.  I think the overall scenario you are running into is quite common.  But I would strongly suggest an approach that was more flexible than the DVWP.  I certainly understand the restrictions you might be under at a large company, but at the end of the day if the goal is to get the task done I'm always going to advocate using the best tool for the job.  In this case I think the requirements are too complex for SPD -- even if you made it work in 2007 I'd probably still have given similar advice.

    I'm sure you probably don't want to hear that and it doesn't really answer your initial question. But just because it's possible to do something with a tool doesn't always mean you should. It really isn't fair for your company to make such lofty requests but impose such harsh limitations on the tooling you can use.  There are definitely responsible and very effective ways to do custom development in large organizations. Simply ruling them out seems like it wouldn't be the best idea.


    John
    SharePoint911: SharePoint Consulting
    Blog: http://www.rossonmoss.com
    Twitter: JohnRossJr

    MOSS Explained: An Information Workers Deep Dive into Microsoft Office SharePoint Server 2007
    Wednesday, May 12, 2010 3:07 AM
  • Hi John,

    I'll see if the new xsl list view web part can do it, and re-brand the site. 

    S'

    Wednesday, May 12, 2010 3:17 AM
  • Can't seem to figure out how to enable editing the data with a xsltlistviewwebpart like you can with a dataformwebpart...anyone have a link?  all you seem to be able to do is enable addition of a edit link, which takes you to the form I'm having problems with :(

    Started working with a fresh web application to see if a non-attached content data base had any impact...nada.  If I import a wide spreadsheet with around a hundred columns into a list, crack open sharepoint designer, navigate to the list and make a new edit form it builds it...as guess what... a dataformwebpart.  Save it...you can't edit the list anymore.  if you try to edit an item in the list you get the correlation id error message.

    RrrrrrFFFF!

    Wednesday, May 12, 2010 8:30 PM
  • Got my support id this morning, logged the problem with microsoft.  Spent several apparently productive hours with tier 1 and II support.

    Sent a list template, replicated the problem.

    The support tech (Amey Mulay) hand-keyed a list with 95 columns, replicated the problem.

    A conference call tomorrow, ... hopefully a solution soon.  Actually impressed with the microsoft support.  Very methodical, suggested relevant possible fixes and kept working on the problem without telling me i was out-of-bounds wanting more than 70 fields on a web part when hundreds were supported on a list.

    Looked at re-branding, looks like a snap.  2010 actually looks like a good upgrade if I can get past this hurdle.

    Friday, May 14, 2010 2:48 AM
  • Tier III support reproduced the problem and will be submitting this up another level within microsoft. 

    Apparently I need Premier support to get this actioned in a more timely fashion...have a call with the CIO later today, will see if I can get a corporate person engaged. 

    While on the phone with level III support (also had an excellent grasp of the problem and very helpful) Happened to think...there are a lot of web.config's, going to see if one of those has a setting...

    Tuesday, May 18, 2010 2:11 PM
  • Hey Swirch,

    Any resolution to this?  Or at least a confirmation that there is a limit.  I am running into a similar problem where I have added around 80 fields to the form and now just adding additional HTML to my form causes the "Unable to display this web part" error.  The logs show a stack overflow.  I can break my form simply by adding extra HTML and not even another form field.  Adding this "<tr><td></td></tr>" to my table is enough to turn a perfectly working form into a generic "Unable to display this web part" error.

    Michael.

    Friday, June 18, 2010 9:02 AM
  • hi Michael,

    Nope, haven't heard back from MSFT in around a month...supposed to be fixed within six months, maybe.  Did not really get any information from support regarding a root cause or limitation, simply that they could replicate the problem, there wasn't supposed to be a limit, and passed it deeper within microsoft. 

    Don't see any hotfixes yet.  That's where I'm at...there's no formal means for microsoft to notify me of a fix so every week or two I google for sharepoint 2010 rtm hotfix, watch WSUS, haunt the forums, etc.

    You are absolutely correct on the addition of more rows in the table; I took one of my test forms, got it to the point where it was painting ok by one column, added a <tr><td>A</td></tr> and it broke.  It also broke when I added a <td>A</td> on the end of an existing row.  In both cases removing the tags and re-saving fixed it.

    This prossibly explains why large custom infopath forms break too...

    Best regards,

    S'

    Monday, June 21, 2010 6:26 PM
  • I have a custom SharePoint Designer data view with custom newform and editform that both also broke when upgrading from 2007 to 2010. Mine is similar to yours in that I have about 140 fields, and it 'seems' to be how many fields I have.

    Did anyone get confirmation from Microsoft that this is a bug when upgrading to 2010 from 2007 and a large form is modified by SharePoint Designer breaks?


    Linda Chapman | SharePoint Consultant | My Blog: http://LindaChapman.BlogSpot.com | http://www.linkedin.com/in/LindaChapman
    Sunday, January 02, 2011 10:47 PM
  • Hi Linda,

    I saw a mention in a blog a couple of months ago confirming it's a bug...sort of sounded as if microsoft feels it's not mainstream enough to fix and I'm sure they have way more serious problems than this one to deal with.

    Best regards,

    Steve

    Friday, January 07, 2011 7:33 PM
  • Bringing this one back to the top.

    Has a fix been issued for this problem?
    I currently have a list with 117 fields that working in 2007 but not in 2010.  If i reduce the number fields in the edit form from 117 to 52 it works but I need to have it at 117 just like it was in 2007.

     

     

    Monday, April 04, 2011 7:40 PM
  • Hi Danny,

    Not that I'm aware of...sort of ditching the entire sharepoint form controls and going to javascript, jQuery and Ajax.  I'm finding that way I can gain more control, flexibility, and functionality.  It takes a few hours to pick up if you're not familiar with it, but there's no looking back once you do...

    Note that removing the field descriptions and other tags get's you more fields.  Just open the code view in designer, locate the field descriptions and delete them.

    Best regards,

    S'

    Monday, April 04, 2011 7:53 PM
  • Thanks for the quick reply swirch.

    Can you show me an example of how this this look, replacing the <sharepoint:formfield> and <sharepoint:fielddescription> fields with javascirpt.

    Monday, April 04, 2011 8:49 PM
  • Yes, my customer had to call Premier Support and press the issue for about 2 months. It is a bug and as far as I know they don't have any plans on fixing it. Not enough people have called Premier Support regarding the issue. This is why it is important that people call to report problems like this.The more visible it is the more pressure there is to get it fixed. :)

    There is a workaround. You just have to break up the XSL to several instead of one. They are suppose to be posting a KB article about it though.


    Linda Chapman | SharePoint Consultant | My Blog: http://LindaChapman.BlogSpot.com | http://www.linkedin.com/in/LindaChapman
    Tuesday, April 05, 2011 5:11 AM
  • Hi Danny,

    The simplest thing that will get you further is to remove as many sharepoint:fielddescriptions as you can; you can effectively double the amount of form fields on a page.

    If at all possible the next best thing is to break your form fields into two web parts, this will also double the amount of form fields.

    For the javascript bit I'll refer you to the jQuery site...http://spservices.codeplex.com/

    There is a lot of excellent documentation and an active forum to help over the rough spots.

    Best regards,

    S'

    Tuesday, April 05, 2011 11:45 AM
  • Thanks for the update Linda...was more than a little dissapointed with the result of the MS support experience...when they did come back that it was a bug they don't even apparently have a means of notifying that there is a fix for it.  It can be a little tedious to continue googling to see if there is any more information and it doesn't exactly build faith that the user community should invest the time and effort to report the next problem.

    By breaking up the XSL do you mean additional web parts?  I guess I've never even seen a technical note as to what is causing the problem; a blog or KB detailing what the root cause is would help immensly.

    Best Regards,

    S'

    Tuesday, April 05, 2011 11:53 AM
  • Here is the posted work around that Microsoft Premier Support gave us. Please mark this as resolved as this is the documented fix from me calling support.

    Custom List Form in SharePoint Designer 2010 will not render if the list has a large number of columns.

    Symptom

    Custom List Form will not render if the list has a large number of columns. To reproduce this issue create a custom list and add 68 single line of text columns. The custom list form web part will not render and an error message such as this will occur in the browser:

    Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Microsoft SharePoint Foundation-compatible HTML editor such as Microsoft SharePoint Designer. If the problem persists, contact your Web server administrator.

    Correlation ID:

    For more information about custom list forms please refer to this article:

    http://office.microsoft.com/en-us/sharepoint-designer-help/create-a-custom-list-form-using-sharepoint-designer-HA010378258.aspx

    Cause

    This occurs when a large XSL transforms happens in a single template.

    Resolution

    The issue can be resolved by breaking up the offending xsl template into smaller parts to avoid a large transform.

    This example is for a New Form custom list form. The Edit Form is similar in template naming convention. Please refer to the end of the article for the template names of the various form modes.

    1. Open the page that contains the none working custom list form web part.
    2. Switch to code for this this workaround.
    3. Search for the following string:

    <xsl:call-template name="dvt_1.rowedit"/>

    4. Copy this line paste it 3 to 5 times. The table structure and other components that makeup this template will be divided into the other copied templates. A general guideline is to have about 20 to 40 table rows per template. There is a fair amount of give with this recommendation.

    5. Rename each pasted template by adding a number to the end of it.

    <xsl:call-template name="dvt_1.rowedit"/>
    <xsl:call-template name="dvt_1.rowedit2"/>
    <xsl:call-template name="dvt_1.rowedit3"/>
    <xsl:call-template name="dvt_1.rowedit4"/>
    <xsl:call-template name="dvt_1.rowedit5"/>

    6. Now, press the control key and click the dvt_1.rowedit. This will highlight the template's first line which is this:

    <xsl:template name="dvt_1.rowedit">

    7. Place the cursor infront of the less than sigh of <xsl:template name="dvt_1.rowedit">
    8. Hold down Control + Shift and then press semicolon. This will highlight the entire template.
    9. Go to the bottom of the template. The following should be the last line:

    </xsl:template>

    9. Paste the following markup after the closing xsl temlate tag from stpe 9. In this example there are 5 different dvt_1.rowedit templates calls so we'll need 5 <xsl:template> elements to match.

    <xsl:template name="dvt_1.rowedit">
    <xsl:param name="Pos" select="position()"/>
    <tr>
    <td>
    <table border="0" cellspacing="0" width="100%">

    </table>
    </td>
    </tr>
    </xsl:template>

    10. Rename each of the templates pasted in step 9 to match the templates from step 5.

    <xsl:template name="dvt_1.rowedit">

    <xsl:template name="dvt_1.rowedit2">

    11. Next, the conents of <xsl:template name="dvt_1.rowedit"> needs to be divided among the new templates, <xsl:template name="dvt_1.rowedit2">, <xsl:template name="dvt_1.rowedit3"> and so forth. The easiest way to do this is to start at the end of the template and cut out the last few table rows and paste them into the last template that was created. In this example that would be <xsl:template name="dvt_1.rowedit5">

    The individual table rows that represent the various SharePoint fields are stored inside of the table HTML element and that valid HTML needs to be persisted into the new templates. A good way of ensure this happens is to find <table border="0" cellspacing="0" width="100%"> in <xsl:template name="dvt_1.rowedit"> and perform a Control + Shift + Semicolon to highlight the entire table.

    Once this is done scroll down to the end of the table and carefully take entire table rows, <tr>, and their contents over to the last xsl template.

    By default the following is the last chunk of markup in <xsl:template name="dvt_1.rowedit">:

    <tr id="idAttachmentsRow">
    <td nowrap="true" valign="top" class="ms-formlabel" width="20%">
    <SharePoint:FieldLabel ControlMode="New" FieldName="Attachments" runat="server"/>
    </td>
    <td valign="top" class="ms-formbody" width="80%">
    <SharePoint:FormField runat="server" id="AttachmentsField" ControlMode="New" FieldName="Attachments" __designer:bind="{ddwrt:DataBind('i','AttachmentsField','Value','ValueChanged','ID',ddwrt:EscapeDelims(string(@ID)),'@Attachments')}"/>
    <script>
    var elm = document.getElementById(&quot;idAttachmentsTable&quot;);
    if (elm == null || elm.rows.length == 0)
    document.getElementById(&quot;idAttachmentsRow&quot;).style.display=&apos;none&apos;;
    </script>
    </td>
    </tr>
    <xsl:if test="$dvt_1_automode = '1'" ddwrt:cf_ignore="1">
    <tr>
    <td colspan="99" class="ms-vb">
    <span ddwrt:amkeyfield="ID" ddwrt:amkeyvalue="ddwrt:EscapeDelims(string(@ID))" ddwrt:ammode="view"></span>
    </td>
    </tr>
    </xsl:if>

    This particular table row represents the attachment functionality inside of a custom list form. This should not be in multiple templates and makes sense to go to the last XSL template created.

    All the other table rows, <tr>, should contain the various columns in your list. Again, start from the bottom and work up to keep this exercise easy.

    Adjust these steps accordingly if custom HTML layout is used to display field controls.

    12. Finally, here is an example of the finished product. Each template only contains 1 column and the attachment functionality in the last xsl template. Also, only <xsl:template name="dvt_1.rowedit"> and <xsl:template name="dvt_1.rowedit2"> were included.

    <xsl:template name="dvt_1.rowedit">
    <xsl:param name="Pos" select="position()"/>
    <tr>
    <td>
    <table border="0" cellspacing="0" width="100%">
    <tr>
    <td width="190px" valign="top" class="ms-formlabel">
    <H3 class="ms-standardheader">
    <nobr>Title<span class="ms-formvalidation"> *</span>
    </nobr>
    </H3>
    </td>
    <td width="400px" valign="top" class="ms-formbody">
    <SharePoint:FormField runat="server" id="ff1{$Pos}" ControlMode="New" FieldName="Title" __designer:bind="{ddwrt:DataBind('i',concat('ff1',$Pos),'Value','ValueChanged','ID',ddwrt:EscapeDelims(string(@ID)),'@Title')}"/>
    <SharePoint:FieldDescription runat="server" id="ff1description{$Pos}" FieldName="Title" ControlMode="New"/>
    </td>
    </tr>
    </table>
    </td>
    </tr>
    </xsl:template>

    <xsl:template name="dvt_1.rowedit5">
    <xsl:param name="Pos" select="position()"/>
    <tr>
    <td>
    <table border="0" cellspacing="0" width="100%">
    <tr>
    <td width="190px" valign="top" class="ms-formlabel">
    <H3 class="ms-standardheader">
    <nobr>NewColumn90</nobr>
    </H3>
    </td>
    <td width="400px" valign="top" class="ms-formbody">
    <SharePoint:FormField runat="server" id="ff91{$Pos}" ControlMode="New" FieldName="NewColumn90" __designer:bind="{ddwrt:DataBind('i',concat('ff91',$Pos),'Value','ValueChanged','ID',ddwrt:EscapeDelims(string(@ID)),'@NewColumn90')}"/>
    <SharePoint:FieldDescription runat="server" id="ff91description{$Pos}" FieldName="NewColumn90" ControlMode="New"/>
    </td>
    </tr>
    <tr id="idAttachmentsRow">
    <td nowrap="true" valign="top" class="ms-formlabel" width="20%">
    <SharePoint:FieldLabel ControlMode="New" FieldName="Attachments" runat="server"/>
    </td>
    <td valign="top" class="ms-formbody" width="80%">
    <SharePoint:FormField runat="server" id="AttachmentsField" ControlMode="New" FieldName="Attachments" __designer:bind="{ddwrt:DataBind('i','AttachmentsField','Value','ValueChanged','ID',ddwrt:EscapeDelims(string(@ID)),'@Attachments')}"/>
    <script>
    var elm = document.getElementById(&quot;idAttachmentsTable&quot;);
    if (elm == null || elm.rows.length == 0)
    document.getElementById(&quot;idAttachmentsRow&quot;).style.display=&apos;none&apos;;
    </script>
    </td>
    </tr>
    <xsl:if test="$dvt_1_automode = '1'" ddwrt:cf_ignore="1">
    <tr>
    <td colspan="99" class="ms-vb">
    <span ddwrt:amkeyfield="ID" ddwrt:amkeyvalue="ddwrt:EscapeDelims(string(@ID))" ddwrt:ammode="view"></span>
    </td>
    </tr>
    </xsl:if>
    </table>
    </td>
    </tr>
    </xsl:template>


    Supplemental Information

    The following are the template names for Edit Forms and Display Forms. The same concept applies to these as the New Form templates.

    Display Form:

    <xsl:call-template name="dvt_1.rowview"/> and <xsl:template name="dvt_1.rowview">

    Edit Form, which is the same as New Form:

    <xsl:call-template name="dvt_1.rowedit"/> and <xsl:template name="dvt_1.rowedit">


    Linda Chapman | SharePoint Consultant | My Blog: http://LindaChapman.BlogSpot.com | http://www.linkedin.com/in/LindaChapman
    • Proposed as answer by Fidy13 Monday, June 06, 2011 11:47 AM
    • Marked as answer by swirch Thursday, June 09, 2011 2:42 PM
    Sunday, April 10, 2011 9:39 PM
  • Thanks for this linda...if it's ok with you I'd like to test it first, will then be happy to close out...it does look like a nice work-around.
    Tuesday, April 26, 2011 12:08 PM
  • Linda, thanks a lot for sharing that solution - in my case it works!
    Monday, June 06, 2011 11:47 AM
  • We did try this workaround and it did work for us. My concern is that SP 2010 will not have the same functionality as SP2007. We have hundreds of 2007 sites using custom forms with more than 68 columns. This will be a huge resource drain for us to identify all the sites and then recode each form before moving to SP2010.

    Does anyone know if Microsoft has plans to provide a hot fix for this issue?

     


    cindi bethel carmona

    Update: breaking up the forms into smaller chuncks did not resolve the cannot display web part error. HP has made the decision to roll to SP2010 which will render thousands of our forms unusable...we are also trying to contact Microsoft about a possible solution or bug fix.

     

    • Edited by clbethel Wednesday, September 14, 2011 1:54 PM
    Tuesday, July 26, 2011 3:37 PM
  • I have tried this and all I seem to be getting is

    This Web Part does not have a valid XSLT stylesheet:
    Error: End tag 'xsl:template' does not match the start tag 'xsl:call-template'.

    Can anyone help with this matter?

    I have had a look at the tags and they seem to be right


    Sharepoint 2003 Novice!
    Thursday, August 04, 2011 10:23 AM
  • Our developer did try to break up our custom forms into smaller parts using the code you mentioned. We are still getting web part cannot display when trying to create and new form or edit an existing form. Sometimes one can right mouse click and refresh (sometimes 3 or more times) to get the form to display. This is very frustrating as we have many sites using forms with greater than 68 fields and it is working in SP2007.
    cindi bethel carmona
    Wednesday, September 14, 2011 1:38 PM
  • It would be great to have a a solution for this.

    Any response from Microsoft yet?




    • Edited by Kurtbrae Thursday, October 13, 2011 4:33 PM
    Thursday, October 13, 2011 4:27 PM
  • hi linda,

    I am also getting the same error, but in my case it crashes when we have number of records (rows). For example, when do search on my page from a list by putting nearest date it return 560 records and works fine. But search with other date to get more records it crashes.

    Will this resolution work for my case.

     

    I am new in XSLT ans a solution was already developed since data has significantly exceeded now we are receiving this error.

    Thursday, January 19, 2012 6:29 AM
  • Thank you so much...this is exactly what I was looking for.... :)
    Monday, July 16, 2012 10:15 AM
  • Hi,

    I am also facing the same problem. I have 96 fields. I tried this way but it dint resolve my problem.Please let me know if any on eresolved this issue. I got struck in middle of the project :(

    Thursday, August 16, 2012 3:12 AM
  • What you do mean when you say

    1. Open the page that contains the none working custom list form web part.?

    Non working custom list? appreciate if you could further clarify that sentense

    Tuesday, August 28, 2012 4:36 PM
  • Either you can split the XSL or use Powershell command to increase the timeout. if XSLt transform takes more than 1 second, this error comes.
    • Proposed as answer by KrisSP Friday, March 22, 2013 8:37 PM
    • Unproposed as answer by Steven AndrewsEditor Monday, March 17, 2014 5:41 PM
    Friday, March 22, 2013 8:37 PM
  • We tried Linda's suggestion and it seemed to help yesterday but we're getting the error again today. We eventually tried splitting the XSL into up to 18 different sections and that still didn't help. 

    We are using SharePoint Online so increasing the XsltTransformTimeout value is not an option.


    Wednesday, September 17, 2014 6:46 AM
  • Has anyone tried this solution on SP 2013 (on Premise) forms?

    We tried Linda's suggestion exactly, but failed to get the result.

    Columns on the first set of XSL template (default) shows up and the rest are not showing at all (even in View Source).

    Even in the very simple SP forms, when multi XSL template is included, only the columns from default XSL template are visible.

    Different approach for SP 2013 form??

    Thank you.

    Wednesday, November 26, 2014 7:27 PM
  • Hey Linda, thanks for this great solution. I was banging my head against the wall with a custom new item form that reached at least 63 sharepoint form fields and would not render when I added that 64th form field. After following your very detailed and descriptive explanation I was able to move on with my project. Thanks again and kudos
    Friday, June 12, 2015 11:08 PM
  • Huge Thanks to Linda , you really save my lot of efforts. 

    Below line work as charm and solve the issue

    <xsl:call-template name="dvt_1.rowedit"/> and <xsl:template name="dvt_1.rowedit">

    Friday, June 02, 2017 5:54 AM