XForm reserved names for input fields
There's a bug in the XForm implementation that "allow" users to add a input field with the name "id". I put allow in quotes because in CMS 6, the XForm edit dialog will crash and not let you save the XForm. But in CMS 5+ it actually lets you save it and it will later crash when you're trying to get the form data out. Mohahaha-haha... This is especially evil when migrating over from CMS 4, as there was no problem having a field called id there, so you could have a whole bunch of these just waiting to explode after you migrated.
This behavior is because id is a reserved keyword for XForms. So it's important to tell this to your editors.
And it doesn't stop there. if you import a form from CMS 4 into CMS 6 and get this error, the normal thing would be to delete it and start anew, but oh no. That would be to easy right? Because you can't delete it in XForm editor. Actually you can't do anything because it will crash as soon as it tries to read the XForm's xml definition.
Database to the rescue!
By now you might have started to sweat. But take it easy, you can remove it, but you will have to do it directly in the database. First thing you want to do is to find the offending XForm in the tblSystemBigTable (or the more convenient way of using a view: dbo.VW_XForms). The column FormName hold the XForm's name so you can locate it that way (or using Windmill Explorer). The row also contain the GUID for the XForm. Use this GUID to remove the XForm from the tables it is referenced in by using it as the input for the stored procedure dbo.BigTableDeleteItem. This should take care of it and you should not see it in the XForm browser anymore or in a property.
CMS 5 R2 SP2
"What about me" you say? Well for you it's easier or harder depending on what you want to do.
If you want to delete the XForm and go on with your life, than it's easier, as you can do it as you normally would via the XForm editor. But if you want to extract the data, it's harder.
"Uh yeah that's great, but what about all the data. Can we get that back?!"
Yes! In CMS 6 it's a bit easier because the data isn't serialized, i.e it is in plain text. And every XForm automatically gets its own database view that will show you the submitted data, so use those. If you don't want to use the database you can always write something that takes the values and writes them to a csv file or something similar. And this is exactly what I've done, but for the CMS 5 R2 SP2 version. This because the CMS 5 versions doesn't have any views and the data is serialized, so it's much harder to extract it directly via a SQL script.
The "tool"
This tool is for CMS 5 R2 SP2 and it's not tested at all (well it runs!). The idea is to give you the basic code skeleton and you can then modify it to your needs. So if you are going to use it you should first go through and understand the code and then do the necessary changes. But hopefully it is easy to understand and if you do some improvements you are welcome to post them here for others to enjoy (pleaase do some refactoring, pretty pleeeaase ;).
Installation: Include the files to your project and compile.
Instructions: Input the XForm's GUID (use Windmill explorer to find it) for which you want to export the form data from. The tool then goes through all the form data postings and writes them to a file in c:\temp\xform, so make sure the IIS account has write/read access to it.
The error you receive when trying to save the XForm or export data from it:
Property Id must be of type System.Guid or EPiServer.Data.Identity
Comments