InfoPath Dev

I use an external XML file secondary data source for my Infopath forms. I have been unable to specify a relative path to the file ie .\myApp\secdata.xml
It only works if I specify a full path with drive letter.
The data files change frequently and are automatically updated by email from the SQL Server.
I need flexibilty so that I can run the forms off a local Web or server share, or Sharepoint, rather than local machines.
I can't embed the several secondary data files in the forms--that would make them too huge for the narrow email bandwidth that I have available. And many forms use the same secondary data sources. And the email system is locked down by corporate policy; it won't accept XSN files or any executables.
At the moment, I would classify it as an InfoPath bug or design limitation..am I missing something?

Does the form environemtn change folders often? I would think that an absolute path would be prefereable if you had several forms referencing the same XML.

Do the names of the data files change frequently? If they stay the same name you can add the XML document as a secondary data source via the wizard in InfoPath:

1) Choose Data Connections from the Tools menu
2) Add -> Receive data -> XML Document -> Browse to File
3) Click Finish.
4) Click No on the dialog that appears, this will leave the data source outside of the form and allow dynamic updates.

Hope this helps!


---------------
Matt Faus
InfoPath Dev Texas

The environment can be a local computer hard disk, a Web site, a share on a server, etc.
Currently everything is installed locally on each client machine--which we need to move away from toward a central location on each site with one copy of the forms and one copy of the data files.

Unfortunately, each location is unique, and I have little to no control of it. The only thing consistent is the the XML secondary data files are one folder below where the forms are located. And the users will have a shortcut on their desktop to the form(s).
The wizard fails if you don't specify a fully qualified path including drive letter.
It seems like a major design flaw.
I even tried hacking the xsf file directly, and that fails too--get error that it can't open the XML file.

Hi Rick,
Sounds like an architecture flaw in your solution. Why are you storing the secondary data in files on a server? Why not just query from the form? The other idea would be to use some .NET caching support to get the info down. At any rate, your solution needs to be Full Trust to access a file on a drive and that's a bad design. Need to use some Domain Trust best practice.

Patrick Halstead [InfoPath MVP]
InfoPathDev

The sites have intermittent Internet access on small bandwidth channels --they are cruise ships. The forms are installed from cd, and all data is sent via email, both directions. Secondary data is updated by sending XML files to each client via email. Form data is sent by email directly to the SQL Server to be bulk uploaded.
All forms have full trust and signed on a very secure internal environment.
It's a very robust, secure system, but we need to reduce the bandwidth used to transmit updates.
The best I can do now is put all the forms on a server, but all the secondary data sources would have to reside on each client.

I'm still a bit lost. The client has InfoPath installed. You are putting the InfoPath templates (XSN files) on a server. The client has limited access to this server. If you can send the secondary data to the client via e-mail, why not just send a new copy of the form down via e-mail? Same thing, no?

You could stash the XML file in the Internet Cache and use code to get to it. That's where all of the InfoPath form templates are cached. SolutionURL will point to the installation location of the form, so another solution is to have them install the form locally by creating an MSI with regform which always installs the stuff in the %AppDir%\[Your Company Name]\[Your Form Name] and then look in the registry when you want to save the XML file.

Still, I favor sending out XSN refreshes in e-mail and installing locally. There is a feature to do this in the Designer but it only works for restricted forms which isn't an issue if the 2DS (secondary data source) is in the form. If that's not possible, consider the MSI idea. Or just install your forms to the same location on all machines and use SolutionURL to get the location from your code.

Patrick Halstead [InfoPath MVP]
InfoPathDev

Can't send the XSN files through email for two reasons. 1. all executable files blocked in email, no exceptions. 2. They are way too big for the narrow bandwidth pipe. I am breaking down the larger XML data sources into smaller ones so the updates are smaller.
One of the other main problems with all the data files local on each client is that inevitably some of the systems don't get the latest ones, causing the IT Officer to track it down--he is way over worked and is thrikked to have to do it on a regualar basis. Having one set of data files and one set of forms per ship makes administration considerably easier.

A good solution would be to use Sharepoint, but they are having trouble getting it to work because of the narrow bandwidth.
Unfortunately, someone in marketing had the bright idea of selling VoIP to the crew and passengers as a new revenue stream, and that eats all bandwidth 24/7.
Unfortunately, a lot of the problems are politically caused, not technical, and I can only do what they allow me to do..the client is always right.

Haha, man that's depressing. Good luck and let us know if we can do anything else to help!

---------------
Matt Faus
InfoPath Dev Texas

I'm hoping that in the 2005 version of InfoPath they allow us to use relative paths for sec data source.