InfoPath Dev

Hi all,

I have a form (MOSS 2007) that is running really slowly after adding 4 secondary data sources back to 4 SharePoint lists containing 600 odd entries each.
There are 4 drop down lists linking to the 4 secondary data sources (clients split out A-C, D-F.. etc to reduce the size of the initial load from around 2000).
When a client name is selected, 5 associated address fields are populated from the the name field.
I have 8 views that progress a process:-
1 - with the client drop down fields available for selection
2 - with the client drop down fields in a hidden field so it has to be explicitely opened to update the data
3 onwards - I have removed the drop down fields and replaced them with data fields that are not updatable, removing the hefty round trip.
The latter forms load and process much more quickly but are still too slow!

I cannot find hard and fast limits for secondary data sources linked to lists, and I cannot think of a way to load the data even through code to spread the loading..

The form needs access to this source data - any ideas?
a) am I asked too much of my form to collect that much data?
b) if I am, I can't think of a way that will reduce or spread the collection..I've thought about coding to add the data 'on-load' as xml to the form, but that just moves the problem.. I could split out the customer lists further to make them smaller..is this an acceptable request for InfoPath and a browser, in which case this is therefore a capacity issue with the MOSS server or more likely bandwidth between MOSS & SQL..??

Am i asking too much?

thanks anyone..

Hi Rebecca,

You need to filter the lists on the server to prevent pulling down all 600 items for each one. You can use Qdabra's qRules v2.0 to do this without code - check out the FilterOwssvr example here: http://www.infopathdev.com/files/folders/qrules/entry49214.aspx. There's also a forum post on this here: http://www.infopathdev.com/forums/p/13963/49740.aspx. qRules gets injected into your form and because it reduces the amount of data pulled down from SharePoint you will see performance improvements as a result of a) less items in dropdown list, b) less time to download items. qRules works by calling built-in SharePoint functionality that filters a list. Normally you would have to write code for this, but qRules enables it using a rule.

Another approach is to use a Web Service to filter on the server. Qdabra has a free trial download of WSSP that essentially does the same thing that qRules does. Here's a link: http://www.qdabra.com/en/products/wssp.aspx. Note: you can use WSSP to filter items in SQL as well as SharePoint. Here's a link to some Performance data showing how much faster it is to use WSSP than SharePoint alone: http://www.infopathdev.com/blogs/ernesto/archive/2009/01/07/dbxl-v2-3-performance-analysis.aspx

In summary, you can make it work by using server-side filtering. Filter Owssvr is one method and using a Web Service is another. Filter Owssvr requires code or qRules to use from the client. Web Service has to be implemented, or you can leverage the Qdabra's free sample and if it works the Web Service is pretty cheap (~$500) and can be used for all of your forms.

Hope this helps,

Hi Patrick,

That looks spot on, thank you. I will try the qrules to pull the data on demand first but Qdabra looks great so I'll investigate that too.

 Thank you very much for your response