InfoPath Dev

I'm using InfoPath 2010... I have a user unable to get their work done as a result of this failure. I would appreciate any and all help!

I have modified a published template for use at another physical location. I edited the manifest.xsf file and changed the location references and rebuilt the cab (xsn). I copied it to a LAN directory at the new location. Users access the template from a shared library. All but one user at the location can open the template. For the failing user, I have cleared the cache and removed all references to the recently opened templates. After clearing the cache I rebooted the computer and it still fails. Here is the message I'm getting:

------------------------------------------ 

The form template associated with this form was moved or cannot be accessed. The form template "Review_Individual_Service_and_Support_Plan" on your computer has the same form ID as the template associated with the form, but it is from a different location.

Location of the associated form template: \\SP2\InfoPath_Templates\Review_Individual_Service_and_Support_Plan.xsn

Original location of the form template on your computer: \\Sp2\infopath_templates\Review_Individual_Service_and_Support_Plan.xsn

Make sure you can access the location of the associated form template and try opening the form again. If that does not work, ask the form author to update the form.

------------------------------------------

I have questions and hope someone has answers:

1. Now that the cache was cleared, how does it know what the "original location" was? Is it keeping information in the registry I don't know about?

2. You'll note that the failure is resulting from upper/lower case differences. The location and name of the file I'm trying to open is the upper case version, and that's what's contained in the manifest.xsf file. How is it even TRYING to look for the lower case version?

3. Why doesn't clearing the cache remove all references to the "original location"?

 I have some additional information. A form with a different name was doing the same thing. I was attempting the same remedies and somewhere during that process the problem for the other form ceased.

At this point I wouldn't classify myself as inexperienced, but I've never seen THIS problem before!

Thanks

Dennis

I saw a suggestion elsewhere to remove the publishURL clause from the manifest.xsf. I tried that and it didn't fix the problem.

I'm pretty sure IP is going to helpfully put that publishUrl attribute back when you save the xsn (unless you do it without using the designer).

It seems like the type of issue clearing the cache could resolve - but was it a full trust template? Was it installed on the user's machine? If so, there will be registry entry....

Thanks for replying Hilary! Always nice to hear from you.

 I didn't republish. I simply uncompressed the cab, edited manifest.xsf to point to the new location and used makecab to put it back together. Since then, another user seems to be having the problem. The last thing I tried was setting the href in the manifest to the exact mix of upper and lower case that the error message seemed to show. Then I cleared the cache and some forms based on the template opened successfully, but I could still not open the template itself in form-fill mode OR in design mode.

Just got back from the Oregon-Cal game (Oregon 43, Cal 15!) and stopped in to check email. I'll be back at this problem in the morning [sigh]. If I find the reason for the failure, or a fix for the problem, I commit to posting back the solution.

Dennis

Can I ask a silly question? Why all uncab - makecab? Why not just publish?

Thanks for responding! Not a silly question at all!

The only way I can reach the locations from here is via Teamviewer or LogMeIn. They're not part of an integrated network. There are 7 remote locations and about 50 different templates. Unless there's a way to automate the publishing, that means I'd have to manually publish 350 templates. I CAN automate the "uncab/makecab" and editing process, saving tons of time. For 6 of the remote locations this works beautifully. This 7th one has been a problem.

Obviously it looks like InfoPath is case sensitive. My morning's research has shown that different versions of Windows treat paths to shares differently. This remote location has a Workgroup. I've put the templates on ComputerA (not its real name [grin]), then created a share that will be visible to the other members of the WorkGroup. On ComputerA, the path to the share is: \\SP2\InfoPath_Templates. When I access the share from ComputerB, it sees the share as \\Sp2\infopath_templates. This means that depending on how I publish the access path, it will fail at one location and not at the other. I'm now convinced that the problem is not with InfoPath, but with Windows. I've called our network administrator for a meeting to discuss the Windows inconsistency.

I'm putting the InfoPath part of this problem on hold for now. The problem with case sensitivity is in Windows, not InfoPath.

 Thanks again!

Dennis

Final note from me:

In my automation routines, I forced the href in the templates to match what Windows was changing the path to on all the machines at the failing remote location. I modified all of their exacting forms based on the templates to match as well. All three users at that location are now working as anticipated. InfoPath was not the cause of the problem. The Windows issue with changing the case of the path remains. I've taken that up in another forum.

Thanks for your help and patience, Hillary!

Dennis A Schaefer
Database Coordinator
Willamette Family Treatment Services
Eugene Oregon