I spend a lot of my time looking at the FileMaker Database Design Report for BaseElements. So I see lot of the options and permutations that are possible in various FileMaker files. One that seems to come up a lot more often than I’d like are FileMaker files that produce invalid XML, which makes it impossible for BaseElements to import.
Even more frustratingly lately I’ve been seeing bad layout data that doesn’t throw any sort of error, just silently fails on import. An error that gives you some sort of error code is fine, you can at least work around it or allow for it and manage it. A import with no error code means you need to know how much data SHOULD have been imported and you can compare it to how much data was imported.
In the case of BaseElements we start with a list of all of the files in the solution. Then we have a second import that is using the setting “update matching records in found set”. So when this runs, if there is an issue with one of the files, there will be fewer records in the found set afterwards. Count the before and after and you have an error capture where there is none.
In BaseElements 3.0.8 I added an error dialog for exactly this and just put a fairly generic “contact support” message in it, as I wasn’t sure at that stage if it was actually corruption related, and also I didn’t think this would occur very often. Well it turns out to be more common than I thought, as I’ve had a couple of reports already. The sample files confirmed that it was corruption related, and were enough that I could pinpoint when it happens. As of version 3.0.9 the dialog will tell you which files are the issue, and direct you to this page for more information.
What do I do about the error?
If you have received an error dialog from BaseElements that the file might be corrupt, or if you have any problems when generating a HTML Database Design Report, there are a couple of steps to go through, to try to find out where the problem is.
First, you can run the recover process on the file to see if that reports any changes. This may give you enough detail in the recover report to locate what changed. Also you can re-import the recovered file’s DDR to see if that solves the issue. It helps if you have a before and after import in BaseElements so that you can compare them and find any changes that the recover operation caused. ( Obviously if you can’t import into BE because of corruption, that may be an issue. )
Second you can try to pinpoint the problem in the DDR by using some text editing applications.
How to locate the corrupt elements
You’ll need a text editing application that can validate XML. This could be something like the XML editor Oxygen or a plain text editor like BBEdit or TextMate. ( I do all of my development on a mac, so apart from Oxygen, which is cross platform, I’m not aware of other apps for Windows that have this functionality built in. If you know any please let me know in the comments.) In this example I’m going to show how you use TextMate as it’s provides a quick and easy way to locate the issue.
Open the file in TextMate and run the “Validate Syntax” option in the XML Bundle menu. This produces a new window with the results of the error like so :
The first error about utf8 and utf16 you can ignore. The second one is what we’re interested in. Click on the item and it will take you to the location of the issue in the DDR. The problem here is that 99% of the issues I’ve found are problems with Layout objects and these are the hardest to locate. For example you might end up with something like this :
Which probably means nothing to most people and isn’t much help. The other issue is that the errors always seem to manifest themselves as missing closing tags. So in this case the example is that it’s missing a LayoutCatalog tag, but it tells you that this error is right at the end of the layout. So you don’t actually know which layout it means, that detail is right back at the start.
To find which layout it’s on, you need to search in reverse for the opening Layout tag. So do a find for the text “<Layout ” ( with a trailing space and without the quotes), and click on “Previous” instead of the default “Next”. If you’ve landed on an actual layout tag, it will look like the following :
<Layout quickFind="True" includeInMenu="True" id="32770" name="LayoutNameHere">
If it’s a layout start tag it will look exactly like the above but with names and numbers changed, it will all be all on one line, and have no indenting at the start. If you find something similar but not matching those criteria, keep searching. ( The reason for that is that the Go To Layout button also has a similar look, but is usually indented and doesn’t have all of the same values. ) The layout name is in the position above where it says “LayoutNameHere”.
I’ve found it, how do I fix it?
I would start by deleting that layout and re-running the DDR to see if that resolves the issue. It may not be the only one, so you may need to repeat that process with one or more layouts. Alternatively you could delete the items from that layout but leave the actual layout intact. If either of those solve the problem I would go back to your original corrupt file and recreate the layout from scratch. That is going to be safer than copying any items from it, as you may end up copying the problem along with the items, or you may only get incomplete items copied.
You can then use BaseElements to see which items were referring to the layout and modify them to point to the new one.
Help 🙂
If that sounds a little too difficult of if you don’t have access to the applications that can do this, we’re happy to look at the files and issues you’re having and see if we can locate the problem for you. If you’re able to share your DDR files with us, open an issue on the BaseElements support page ( you can mark it private if you don’t want to share the file with the world ) and attach a zipped version of the DDR XML files that are mentioned in the error dialog. We will have a look at it for you and identify the locations we can see that are causing issues.