InfoPath Dev

Hello - I would like to see if there is a way to query data into a repeating table that was submitted to a SharePoint library from a similarly structured repeating table please.

By setting the columns in the first, submitting form to "merge" when publishing, the inserted data loads into the SharePoint library in separate lines; but when I try to bind the querying fields in the second, receiving form to the fields in the secondary data connection (which is the SharePoint library) I get an error message saying I can't bind non-repeating fields to repeating fields.

Then I tried setting a default value for one of the repeating tables, linking it to the appropriate column in the SharePoint library, but then it gives both test entries for that field in the same text box, instead of loading the second test entry into a second table. I have the tables in the second form set as repeating since I don't know how many entries there will be and to take up less space.

The first form, which submits to the SharePoint library, is for Managers to be able to specify parameters for a project:

• Form 1 structure: includes a Repeating Section with a text box for a parameter plus a repeating table for descriptions of each parameter. Manager inserts a new section to add more parameters & their descriptions

It would be neat if the second form can query the Managers' parameters & associated descriptions in the same format (same repeating tables), so that the representatives that use these second forms can view those parameters and then provide their more detailed input about each point for the Managers' review:

• Form 2 structure: includes all the elements of Form 1, along with a repeating table within the main Repeating Section, where they provide their detailed input for each parameter

Any ideas you may have about the best way to approach this scenario will be greatly appreciated!!  Thanks very much, Boerkie -

That's because it goes into SharePoint as a text string, not a repeating data source.  In SharePoint, the repeating data source is the list/library itself, and each record is a repeating entry of that group.  SharePoint does not have repeating fields within repeating records.  This is a known limitation and is not a bug, nor are you doing anything wrong.  Qdabra - owners of this site - has a solution for this, but it's nothing out of the box.

In your case, though, do you really need 2 forms?  I'd do one form with multiple views and show fields as necessary.

Thank you so much for your response!  I have restructured the info into 1 form as you have suggested, but may I please ask how the fields would be shown or hidden? Also, would using Reference Fields or Groups help with this at all?

Many thanks, Boerkie

You can show/hide fields in many ways.  You can do it all in one view with conditional formatting, or you can do it in multiple views with conditional formatting or omission.  You can auto-send people to certain views based on identity and can restrict/show controls based on identity.  Review my blog posts that talk about this.  They are showing how to incorporate custom user roles in browser forms, but with a rich client form, you can use the built-in User Roles functionality:

InfoPath - User Roles in Browser-Enabled Forms Using AD Groups

InfoPath – User Roles in Browser-Enabled Forms Using Contacts List

Thanks so much once again for this wonderful information!  I have read the info on both the links you sent and think that I will be able to use these concepts for certain projects; however, in this case since our managers (actually account managers) determine the parameters of projects, as well as provide details just like the other team members, and most team members are also account managers for certain clients, I don't know if I can use this particular solution and wonder if there might be another approach that would work please? I apologize for not describing these roles more thoroughly before -

Maybe there is a way for the project parameters to be entered by the account manager for their clients on a special "Account Manager" view that everyone else on each client account team knows not to go to, and then those parameters would somehow appear as uneditable text on another view where the team members, as well as the account manager, then enter their project details? We definitely wouldn't want the team members to edit the parameters by mistake.

I have the project parameters field setup as a repeating section, so that the account managers can go in and add parameters one-by-one (secton-by-section), along with adding the descriptions of each parameter one-by-one in a repeating table which is nested inside the parameters repeating section.

The other view which would be for entering the project details for each of the parameters and their associated descriptions also includes an additional section for entering the detailed input, which is nested within the parameters section.

Would you by chance have any other ideas which might work in this setup please?

I really appreciate all your help with this!! :) Thank you, Boerkie

I don't know what to tell you.  I would still use the methods I've shown you to do all of that and am not sure why they don't work.  I understand how pre-existing AD groups wouldn't work if you have such an undefinable mix of roles within your people, but you can define these roles in a Contacts list very easily, or you can do it inside the form itself upon intial creation.  The first person who fills out the form could be the "account manager" who then has special privileges to the form that others do not have.  That seems easy to me, but that's based off my understanding of what you've said.

Hi again - I actually think I might have found a solution to this in copy the repeating table to a new view and then setting only the "parameters" fields to read only. Thanks so much for your amazing knowledge & input that has lead me to this discovery!!  Boerkie

Thanks so much for your reply - I really appreciate it and have just a few questions if you might have a moment to let me know your thoughts about these please:

1. I tried connecting the secondary database to GetCommonMemberships for the AD groups and to GetUserProfileByName for contact list and am getting the following error message when I try to preview the form. Would you have any idea of what I'm doing wrong please?
• One or more data sources that are required to open this form are not available. they may be temporarily offlineor your computer might not be connected to the network.
• The query cannot be run for the following data object: GetCommonMemberships (or GetUserProfileByName, in the second case). InfoPath cannot run the spcified query. Access is denied.
2. I'm not sure how I would define the various roles for each person on their contact info, since I'm thinking I would need to mark each person (over 100 people) as being account managers of several clients and team members of many more that are always changing. I see that I need a much better understanding of how user definitions (if that's an ok term to use) relates with access on SharePoint & InfoPath forms and any direction you could give me on what to study to learn more about this would be great!
3. Lastly, how do I set the first person to complete the form to have special privileges please? That sounds really neat!

I am so thankful for all your help with this!!  Boerkie

1. If access was denied, then you may have a SharePoint configuration that isn't right, or you're logged into a machine with credentials that aren't recognized in the profile database.  Are you using MOSS and not WSS 3.0?  If so, is there an SSP?  There has to be for this web service to work.  In SSP Admin, do you have the Personal Features permissions within Personalization Services Permissions?  Is Anonymous Access disabled on this web application (it has to be)?
2. I don't know of any published resources for this.  The thing we're doing is only specific to InfoPath and not SharePoint as a whole.
3. Create a "Submitter" field and save the submitter's info to that field for later use with conditional formatting and such.  Just set that field's default value to the function userName(), and that should work.  whenever someone opens the form, check the userName() function against the value of that field.  If they are equal, you know it's you're original submitter, and you can set conditions accordingly.

Thank you so much! I have learned that we have MOSS and our site administrators are looking into our settings, so that I can setup that secondary data connection. I haven't had a chance to work with the "submitter" field yet, but look forward to working with that.

 Many thanks!! Boerkie