Asked By RichardHarbridg
03-Dec-08 10:09 AM

I was able to do a 'workaround' using XML and the owssvr.dll however this is
an extremely limited workaround comparatively speaking.
This is a potentially large issue and I really want to push for it's
resolution, so I am going to illustrate the steps needed to reproduce this
issue in InfoPath/SharePoint:
1. Create a SharePoint Managed Path that directly follows the root with
explicit inclusion. Name this a department name as an example (HR, Sales,
etc).
2. Create a site collection in that new path.
3. Enable all the features (enterprise etc).
4. Create a simple form in InfoPath (no need for fields). Add a data
connection to lookup the values of any SharePoint list in the new department
site collection.
Ensure this data connection is set to grab the data on form load (or you can
use the refresh button, whatever works for you.)
5. Publish the form to an infopath form library in SharePoint.
6. Open the form.
At this point you should notice a typical 5566 error message and the event
log on the Server will display an event like what I listed above.
At this point my assumption is that for whatever reason the infopath
SharePoint data connection has been designed without considering managed
paths and their impact. Remember the connection is under the same domain, so
it shouldn't be a cross domain issue which removes that complication. The
fact that the xml method worked fine also proves that the list exists, and
it's not a access/security issue.
This leaves only my previous assumption thus far.
Anyone's help, ideas, or advice would be greatly appreciated,
Richard