Repeating Tables, breaking apart the data - InfoPath Dev
in

InfoPath Dev

Repeating Tables, breaking apart the data

Last post 08-12-2009 08:19 AM by KarenSL. 2 replies.
Page 1 of 1 (3 items)
Sort Posts: Previous Next
  • 08-10-2009 04:14 PM

    Repeating Tables, breaking apart the data

    I'm sure this has been discussed a million times, but I'm not finding what I need.  I have a form with a repeating table and one of the fields I need to promote to Sharepoint in individual fields.  How do I get those values from the repeating table split into the separate fields?

     Example, it's a routing form..The form needs to route to 3 departments so 3 lines are added to the table, deptA, deptB, and deptC.  I need the field Routing1 = deptA; Routing2 = deptB; and Routing3 = deptC.  If someone comes along and deletes a row, say deptB, I need the fields setup as: Routing1 = deptA; Routing2 = deptC; Routing3 = blank.  I'm setup to handle up to 20 rows and have 20 fields setup in SP.

    I'm running IP2007, no access to the code-behind, SP2007 MOSS, browser-based form

     As a side note, I have this mostly figured out by way of any time a new row is added it checks the sequence number and moves in the value...the problem I'm having is on the deletion, it's not handling the value changes so I'm hoping that if I build the fields just before they go into SP, it'll help alleviate that problem.

    Thanks for any suggestions.

    Karen.

  • 08-11-2009 05:49 PM In reply to

    Re: Repeating Tables, breaking apart the data

    Hi Karen,

    It's a SharePoint limitation. It's the main reason we developed our DBXL Web Service (Qdabra.com -> Products -> DBXL) 5 years ago and one of the reasons it is so popular. SharePoint schema is flat. You can't map variable node repeating groups to a SharePoint list/library because SharePoint lists/libraries are limited to a fixed number of columns.

    Hacky solution is to promote the values for your departments as separate fields: deptA, deptB and deptC. Add a rule that copies values from deptC to deptB when it is deleted. You'll need another rule for when deptA is deleted to copy from deptB to deptA and deptC to deptB. You'll be limited to number of columns you can do this with though.

    General best practice is to map your data to SQL tabes (parent-child) and display the SQL data in a data view. Download our free DBXL trial. Set up a Database mapping and then use a Data View (use SharePoint Designer to define) to pull your data into a web page. If you like DBXL, the pricing starts at $395 for a beginner license. Cheap considering all of the value you get.

    An even cheaper option is to use our free qRules which will support mapping XML to SharePoint lists when version 2.0 comes out. We're looking for energetic beta testers who will spend a couple hours testing for a free copy of qRules 2.0 (currently, 1.7 is free but we expect to sell 2.0 for $199). Beta testers will get it for free.

    Sorry I couldn't give you a silver bullet!

     

    Patrick Halstead
    Project Manager at Qdabra
  • 08-12-2009 08:19 AM In reply to

    Re: Repeating Tables, breaking apart the data

    Thanks for the info.  Question about the hack...how do I tell it to run the rules on the delete?  With what I have now, I have rules on the department field in the repeating table to move the data around into separate fields based on the sequence number except on the row delete it's not running the rules if all the user does is delete a row...meaning, if they delete a row and add a new one the rules sorts itself out, but if they only delete a row and submit the form, the rules don't run so even though it's gone in the form, the fields aren't getting updated.

     Thanks again!!

     

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