I'm curious. How many of us are using the DDR as a part of their developer toolkit?
If you are using it, what are the pros and cons?
I'm a heavy user of the DDR
2 Likes
I am a heavy user of the DDR. Pro: fairly easy to search the HTML version of the DDR. Con: both versions of the DDR are incomplete.
1 Like
The DDR is the free tool. But searching in the DDR is a major pain 
. If not FMPerception would have not been created.
I have stopped using the HTML version a long time back to rely on 3rd party tools that work with the xml version. I believe the HTML version could be lacking on some aspects that are represented in the XML, but I am not familiar with possible disparities between those 2 formats.
I do not see any cons to using the DDR as part of the developer tookit.
There could be some issues if the code contains information that needs to be protected (api keys, or similar), but other than that I cannot think of problems that would arise from using a DDR.
1 Like
I'm thinking more about usability, as @planteg mentioned, the DDR (well, xml really) is hard to search. For a long time I've used BaseX. It's great but it's a generalist tool, not FM focussed.
I would have a very tough time meeting my development tasks without a DDR and a tool to interpret it.
I use the XML version, and sometimes I may run several DDRs on the same solution within the span of just 30 minutes. Typically this happens if I am removing old code.
Otherwise, for general use, I tend to run a new DDR before I sit down for a session with a solution, and I use it to find references to items within a solution. A lot of times I am sitting down with solutions which are unfamiliar to me, and so my work is much easier to be able to track down the references.
This is a great point. Some security precautions are in order, to make sure that no one gets their hands on a DDR, as, at least historically, some creds can be included in plain text within the output.
most of this is still valid 
FMPerception. Always 
4 Likes
DDR is used here very often (although there are days without using that). Sometimes as html, but mostly as xml-output and then processing further with FMPerception.
We are also using FMComparison from the same author (based on xml-export, not DDR)
I import the DDR into Base Elements to look for errors and unreferenced fields, etc.
I was a BaseElements user too, but on large DDR it takes an age to load. That's OK if the system is stable but my work was always about making change. I couldn't wait an hour for BaseElements to load when I really wanted an immediate change report.
At that point I started to design a tool that used a web front end and allowed me to drop a DDR into a folder and begin exploring it and to do an XML sensitive difference report. I'm curious about whether there is sufficient interest for me to put any effort into commercialising it as an online service.
2 Likes
Kudos to you, Malcolm. Mine is the same story. Back when the current version of FMP was v11, I was working an in-house situation where BaseElements was the tool of choice. I started writing my own DDR tools at that point, and have never looked back.
Interesting. I have the impression that a lot of devs will have their own toolset for the DDR.
never tried on that, first because FM-XML in the DDR is such a mess and second because change is not documented and third because of - in my case - CrossCheck as a tool ready to go that extracted all the info I needed.
I've been using FMPerception for a number of years now. Prior to that, is was searching the HTML DDR's. FMPerception and similar tools are way better. I can't imagine going back to searching the HTML DDR's at this point- that would be a severe impact on productivity.
1 Like
My files are relatively small, so BE loads in about 10 minutes. Not ideal, but I can live with it. (I only run the DDR once a week.)
I’ve installed a trial copy of FM_Perception (which loads faster) but the interface does not seem as intuitive.
1 Like