InfoPath Dev

Hi, I'm wondering if anyone has seen this before. On one of my forms, I'm getting an error when trying to load the form after publishing it to a SharePoint form library. The error is: Schema validation found non-datatype errors. Every blog post I see about this error references setting nil values in XML via code. My forms are not running any code other than the injected qDabra features. Unfortunately, this isn't consistent between my forms. I'm using the qRules 4.2 trial version. Any ideas are greatly appreciated. Thanks Dan

Did this start immediately after you injected qRules, or does it happen when you use certain commands?

Yes, it occurs directly after injecting qRules - but only for one of my forms.

Can we have a copy of the form - before injection? Can you send it to Support AT Qdabra DOT com and reference this thread?

Thanks so much!

Just to update with our email thus far - at this point you think it may not be a qRules related issue - let us know what you learn!

Yes. Sorry for the confusion. I'll let you know the end result.

Thanks again for looking at this so quickly

Dan

Ok guys. I'm back at qRules again, but I do still think it's a loose connection. Now this is happening consistently in all of our forms. Here's what we're seeing: 1. We're continually adding fields to our forms and moving them around as we are in the development cycle here. 2. Each time we seem to modify the XML format - even if it's to reorder what field is first in the fields list (i.e. reordering the XML elements) - and then publish the form we consistently get "Schema validation found non-datatype errors." rendering any existing test data inaccessible. 3. Searching Google for "Schema validation found non-datatype errors." only turns up references to setting non-nullable fields via code (XSI:NIL attribute) - we aren't writing any code, but of course have included the qRules DLL. 4. Now, I don't see how the qRules DLL is running anything at form load - but it's the only "code" in our forms. My struggle is that I'm scared that once we go into production and we need to change something, we're going to break all existing form data and halt the business. Any more thoughts? Thanks in advance Dan

For any InfoPath form (with or without qRules), you can add fields, but you should never remove or reorder the schema. Once you remove or reorder the nodes, you could cause existing forms to become incompatible with the XSN. I believe that's the reason you're getting this error; I wouldn't think qRules has anything to do with this error.

Ok. I've done some more testing. I created a brand new form and set up a bunch of fields. I started simple just using text fields and published it to a new library in SharePoint. Then I added a new file to that Library with the recently published form template. Then I added date fields and attachment fields so that I was testing with complex objects. I re-published and had no problems opening the XML file in SharePoint. Then I moved the attachment and date fields into other groups to simulate changing the XML schema, but publishing didn't cause any issues. I tried to move things around one more time and no issues with publishing and opening my originally created XML file in SharePoint. However, once I injected qRules into the form and simply published - I got the "Schema validation found non-datatype errors" message. So, I created a new XML document off the new template in SharePoint and entered some data. Then I went back to my template and simply moved the Attachment field into another group and republished - and received the error again.

I've attached my original Form. Of note, if I republish this form then both of my documents in SharePoint load without issue.

So, given this, I feel I've proved that restructuring our InfoPath/XML Schemas don't cause the error, but the presence of qRules does affect it.

I mention all this in the interests of helping you guys with potential issues - and hopefully arriving at a solution that doesn't hinder us when we're in production.

Thanks Dan

I appreciate the time you are taking and the detail you are providing. 

After moving and renaming your fields - aren't you experiencing data loss when you re-open the XML with the new template?

Do you mind zipping up your sample XML that you created and attaching those as well?

 

Ok. I appologize for bringing this back to qDabra again when it doesn't actually seem to be the case, but in speaking with another team member here, we did another test with no qRules. We simply saved an empty On Load event in code so that the form contained a DLL and republished - and we're now able to break it consistently if we even move one text box up one spot in the Fields list. It seems that the difference is when an XSN file contains code, SharePoint runs it through a different validation engine which seems to be unreasonably strict in its validation.

So, I'm not sure if there is something we need to configure on our Forms Server side which will make this less risky, but I have now proven the other direction, that this isn't an issue with qRules.

Thanks for your help and patience.

Dan

 NOTE - I see you have added to the thread that you had a similar discovery while I was typing the below - looks like all forms with code behave like this. HOWEVER - I highly recommend you NOT move or rename schema nodes once your form is in production - you will lose data.

********************************************** 

Just to add a bit more info - Ernesto walked through the same scenario you did - with the same results. IP doesn't error on renamed / removed / moved field when the form does not have qRules. Instead, it just deletes the nodes that are no longer part of the schema.

So, the next step for us was to check and see if the same results occur with code added to the form (qRules is, after all, a code DLL, just like adding custom code to your form). They do - if I add custom code to a form where I've renamed / removed / moved fields, the XML will not open in the browser with the sandboxed template with the new schema. This is with the form option for versioning set to automatically upgrade existing forms.

Next, I admin approved the template. We have the same result there - schema validation error.

For completeness - I also tried in Filler - and in Filler, I had the same result we have without code. InfoPath just blew the data in the "moved" node away.

Thanks again, Hilary. I completely understand that moving fields between groups will lose data, and while we're in Dev I'm not worried about that of course. What's frustrating (about SharePoint/InfoPath) is that even if I delete nodes from a non-code template and publish normally I don't render previous forms useless. However, once we add even empty code, we can't move, or remove anything without rendering all previous forms unusable which is even worse than losing one node's data.

I'll pick this up with Microsoft to see if something can be done on the Forms server. Thanks again

Dan

If you find a IPFS setting of some kind for this, would you post it back to the thread, just for completeness? Thanks so much!