This may or may not be to the corruption I found the other day 8495 WARNING: - no noticeable issues and no details on what's wrong?
But Exporting the DDR as XML takes about 1-2 minutes. The HTML DDR was going so slowly that we downloaded a backup locally and ran it on the backup, and left it running for 19 hours and it never got past 1/3rd of the way through. In fact it quickly gets to that point and then just stops.
Any suggestions?
Is there any specific reason why you need the html version? It's pretty old and clunky. You can download a tool like FMPerception to interrogate the XML ddr if you need to and it is a much faster and more intuitive interface than a giant html page, just a thought.
Speaking for myself, the HTML can be convenient. It's also a common format that semi-technical folk can utilise if you need to share it.
I have a tools that read the DDR / XML but the convenience factor takes a hit. Of course, if you can't generate HTML because the parser is choking on something then the DDR is the winner.
@JasonMark the fact that the HTML parser is having trouble can be an indicator that there is a problem. You could try figuring out which components are causing the problem. When you choose to generate a DDR you can select whether to include scripts, layouts, etc. Generate separat outputs by choosing only one of the elements. The ones that succeed are (probably) not the problem.
1 Like
As @Malcolm said FMPerception can be pretty cumbersome for basic info. I have a copy but often end up resorting to support and I feel like I’m going to hoops to find what’s easily in the HTML. Don’t get me wrong FMPerception has helped me out but I just see it as one tool.
We’ve narrowed it down to something in the table occurrences around one of two anchors (or maybe both?). More trial and error tomorrow.
good work. Just as a note of caution. I hope that you're doing the exploration in a copy of the file. Once you've found the cause you can return to the production copy and do whatever neat surgery you need to correct the problems.

1 Like
DDR HTML format has been deprecated since FM 17.
2 Likes
oh wow... thanks for that.
The deprecation of the HTML DDR is a shame, simply because it is an easy way to examine the file. It's not clear if the XML component of the DDR is deprecated. The HTML is an XSLT transformation of the XML, so it seems as though an HTML version could always be generated. It would be great if Claris released the source for the XSLT transformations so that community could make use of it.
Claris said that they were putting effort into the Save a Copy as XML instead of the DDR. The DDR was notorious for changing without any documentation, and for not keeping up with the product. The Save a Copy of XML is arranged differently and is a little more complex to handle, It does include more information than the DDR, importantly it includes the last modified account name for many objects.
Like the DDR the Save a Copy has changed internally since it's inception. We were told that it would be changing over time. That in itself is OK. The annoyance is not that new things are added, it is that they modify the structure without any documentation. When we build tools around the output they have to be version limited, because each new version of the Save a Copy XML can change.
1 Like
If my memory is right, this was announced some years ago in a roadmap presentation, sparking expectations among users. That would mean having a complete copy of a file - a backup ? in a readeable format. The DDR is the structure of a file, but the Save as XML would be the syructure AND the data. Just imagine what you can do with that ! And maybe modify a file structure by editing the XML, new possibilities ! Let's see how this will be delivered.
FileMaker is still alive and kicking !!!
Just to clarify: Save as XML, to date, has just been structure only. It's data in the sense of the definitions of all the schema, scripts, layouts, privilege sets, etc. are all a kind of data; but the data that users store in a solution is not part of the content of Save as XML. Still, it is a powerful feature, albeit with the "moving target" concern that @Malcolm called out above.
Thanks for the clarification.