InfoPath Dev

Hi,

While I appreciate library forms are the recommended way of doing this, my requirements are quite flexible so I thought I would ask anyway.

I would like to add a repeating table to the default list form - while I want users to be able to CRUD the child items, I have no rigid requirements about querying the child data later. Therefore, I do not really care how the child data is stored - whether it be another data connection to a separate sharepoint list, SQL table, embedded xml, (using the master data connection to create a delimited field in the parent list seems a nice option if possible) or anything else I haven't thought of.

 Any advice appreciated.

 Regards.

Hi-

The problem is that a List Form has a locked schema - that is, the schema is intrinsically locked to the SharePoint list.

If you design the form, and start adding controls, you're going to run into issues because there is no location in the SharePoint list to store these items.

You would need to modify the SharePoint list, then design the form, and the InfoPath form will show the controls needed for the SharePoint list and its columns.

You also cannot add code to a SharePoint list form, so that prevents you from doing more complex things via code.

So, to summarize, SharePoint list forms are very limited. If you need repeating data, if you need to submit to SQL, or use code... then a SharePoint list form is not the answer. Good luck!

 Hi, thanks for responding.

 I was wondering if you could provide any advice on how to implement these 2 suggestions... I have been trying for several days but cannot get anywhere with either:

 

Using repeating data in list forms

• If you have a SharePoint list form, you have several options for dealing with repeating data other than using the built in support of a form library.
• If part of your content is repeating, consider flattening that schema so that it can repeat. For example, you could limit your book request form to no more than ten books per form.
• You can also use multiple lists and link them together using lookup fields and web part connections. This works well for master/detail scenarios where one list tracks all the items and another contains the specific details for each item.