SharePoint list adapters are really cool because they give you the ability to query a data source that is easily editable via Internet Explorer (as opposed to a SQL database which requires more work to build a UI around data manipulation).

InfoPath relies on getListData web service to return the items from a SharePoint list. Unfortunately, that web service only returns the items in the view.

This is bad since it means that one must modify the view on SharePoint to workaround the default limit of 100 items and that requires different permissions than just querying the list (Contributor vs. Reader).

This is not fixed in the release bits of SharePoint. InfoPath can't fix it. 

WORKAROUND:

Just to bump up the default settings for the view, but how high should the number be set?  On ShP, go to Modify Settings and Columns. Click on the default view. Scroll to bottom where it says item limits. Click to expand, and set from 100 (default) to whatever.

You can't use restricted mode to deploy a managed code (C# or VB.NET) solution in email because InfoPath doesn't allow managed code to run in restricted mode (for good reasons).

You have 2 options:

• Sign the xsn using a digital certificate
  • Pros: the future is digital certificates
  • Pros: publishURL is not removed
  • Con: it will cost you some money to buy one (if you don't already have one)
  • Con: if the publisher isn't trusted by windows you have to jump through more hoops
• Create an MSI using RegForm
  • Pros: easy to do - check it out in the InfoPath SDK
  • Pros: easy to install - no hoops to jump through
  • Cons: removes the publishURL

Q: What's the publishURL?
A: The publishURL is an attribute in the InfoPath form template's PI that describes where the form lives. It is set when you publish to a location.

Q: Why does RegForm remove it?
A: Couple reasons. One: RegForm was created in InfoPath 2003 version 1 as a means to create a URN-based solution (i.e. a solution that is based on it's name, not a location). Two: for security reasons, publishURLs need to be removed before a solution can be “installed“ on a machine. Note: installation is different thing than simply caching as it allows the solution to run Full Trust.

Q: Who cares about publishURL?
A: Ah, yes. The meat of the matter. If you want to create a single form that submits requests from outside (via e-mail) but implements workflow for inside (a corporate network) then your xml forms will have to have the publishURL so that when an internal user opens them it redirects to the internal website where the workflow happens.

Q: Why do it all in one solution?
A: Good point. You can implement the split outside request / inside workflow using two solutions but that would require hardcoding the location of the internal form library in a secondary data source, and it will be more work.

Steps to repro:

1. Create a jscript Form A with the following code attached to a button OnClick event handler:
   
   

   var oXDoc = Application.XDocuments.NewFromSolutionWithData(XDocument.DOM.documentElement, sSharePointTemplate, 1);

   
   where sSharePointTemplate refers to the xsn in your form library, for example:
   
   

   http://sharepoint.company.com/name/Forms/template.xsn

   
   
2. Create a managed code Form B using the same schema as in form A with a button that loads a file from the form library. For example:
   
   

   thisApplication.XDocuments.Open(sForm, (int)XdDocumentVersionMode.xdCanOpenInReadOnlyMode);

   
   where sForm points to the location of the file, for example:
   
   

   http://sharepoint.company.com/name/foo.xml

   
   

3. Publish Form B to the form library that you use for the sSharePointTemplate parameter above. I.e., publish to:
   
   

   http://sharepoint.company.com/name/

   
   

4. Open Form A and click the button to run the code.
5. Form B should open automatically. Click on the button.

Result: error. This is the same error that is documented at: http://support.microsoft.com/default.aspx?scid=kb;en-us;823436

However, I think it's a different problem.

Q: Why do I care about this scenario?
A: If you have a split solution to handle workflow between offline forms and online collaboration, you might want to do this since RegForm removes the publishURL and digital certificates are costly to install (see previous post).

Q: How do I workaround this problem?
A: The easiest thing is to navigate to Form B's form library and click “Fill Out This Form” before running Form A. Then Form B is cached with the correct settings.