I've been using the HTML version of the Database Design Report ever since I started using FileMaker. Back when 17 came out though, it was deprecated. So before it's gone, I want to start using the XML version. I've heard oodles of people say that the XML format is superior, but it's unusable to me as plain XML viewed in something like BBEdit. What do all of you use to view an XML DDR? And why is it considered superior?
FMPerception, BaseElements, or InspectorPro. They are purpose built for FileMaker. They have intelligence. Currently, we use FMPerception. It's fast, doesn't require an import, and has so many features to help you identify and find potential problems, and get answers to your questions.
Also, they just released a companion app, FMComparison, that will help you determine the changes between 2 version of a file ( requires 19, and the SaveAsXML feature ).
Come to the office hours on Thursday. The developer, @DaveRamsey, sits with us and talks about FMPerception every week for an hour. Office Hours - Geist Interactive
3 Likes
Patty, plus one for fmPerception. I don’t believe a day goes by when it isn’t used here.
2 Likes
Hello, Dave Ramsey here.
As Josh mentioned, I'm the developer of FMPerception and FMComparison. Rather than push my own product, I'll address a little more the superiority of the XML over the HTML formats.
Once the HTML export was deprecated, Claris/FileMaker basically stopped development on it, so new FileMaker features were not very well addressed, and known bugs were not fixed. Very large systems could also produce HTML that couldn't be effectively loaded in a browser. The biggest issue is that with the HTML DDR, you're basically stuck with a static text report (plus whatever "search" capability your browser provides). You get one way of looking at the data, and no more. With the XML, developers have been able to build tools that are much more dynamic in what they display and how they display it. On top of that, they can do more than just connect FileMaker elements... They can analyze those connections for functionality or effectiveness.
Yes, all by itself, the XML DDR is less useful to a user than the HTML DDR, but it's not intended to be used alone. Combined with a tool, it becomes far more useful.
And finally (and to toot FMPerception's horn a bit) FMPerception is faster than the HTML DDR. When you export the HTML DDR, FileMaker generates the XML DDR and then uses XSLT to transform it into the HTML DDR. That process takes longer than exporting the XML DDR and then just opening it in FMPerception. The larger the system, the bigger the difference.
All the DDR tools have trials (to the best of my knowledge), so check them out on your system, and see what you like...
8 Likes
I'm using a suite of PHP scripts that dynamically generate information from the XML DDR that I started back when v14 was cool. Like FMPerception, it's secret weapon is that there is no wait time. Produce the XML DRR, place it in the right directory and begin work.
Another tool that I've found useful is BaseX. It doesn't care about FileMaker, so it doesn't handle the DDR in any special way but it's a fun tool to have in the box. It has a bunch of visualisation modes that can be informative. https://basex.org/
2 Likes
Text Diffing the XML is near useless with FileMaker DDRs.
Change a field name and the reference can change in hundreds of places. It’s only one change...not hundreds. There needs to be awareness.
2 Likes
Yes. Isn't it!
I remember in the first videos they used BBEdit to diff a Save as XML copy output. 
another vote for FMPerception.
It is fast enough to be used with quite big DDR, I'm able to find (almost) everything, I can create csv exports and import that into FM - so, I get checklists, etc.
It costs money - but that's ok for that tool
2 Likes
I think you're totally missing the point about the tool. FMperception, BaseElements, Inspector Pro are not XML editing tools. There is zero need to modify the XMLDDR; the only thing you need to do is read it and parse it so that the FM schema elements can be layed out in a intuitive manner, can be marked up, sorted, printed, dependency chains followed,...
If you need a general purpose XML editor then this thread is not for you. That's what Oxygen is for, or even a free tool like VS Code.
If you think Oxygen can produce a result like this:
Then more power to you. Of course you can code your own but pretty sure it will take more than the equivalent of $500 in billable time to get there...
3 Likes
Free has a cost here. So we are definitely not in agreement.
The answers we need, would cost way more than $500/year in the time spent even using the deprecated HTML DDR version. There are things you just can’t do with the HTML version.
Your view here is also very limited because your dev time in FileMaker is very limited. So you may not see the value. For those of us that spend even a few hours a week and have more than the most basic custom app, it pays for itself in just a few weeks. It’s just math at that point.
Besides, there are several features you can only appreciate if you actually use it.
1 Like
And I'm just respectfully pushing back, because I believe you're missing an opportunity to be a better developer and it seems you're hampering yourself solely on cost.
Like @jormond: not a day goes by that I'm not using BaseElements for some heavy duty analysis. Mostly on solutions we inherit to fix but also on my own.
One of the first things we do on any new project is run an XML DDR. For two purposes:
- to have the state of the solution at that time so that we can diff it at any future point (usually before a deployment, but certainly for documentation purposes).
- to do a quick gut-check on the design: what are the design patterns used? What is expensive? For instance: how many layouts have more than 2 portals on it and how many of those are filtered or sorted?
That's a question I can ask of BaseElements simply by creating a script. If you're only using the HTML DDR report you can't answer that question easily. Nor can use it as a decent basis for diffing.
In fact, the use of the XML DDR (and now the save-as-XML output) and the use of any of the big 3 analysis tools is a big part of our review of potential devs to hire. It's that important.
And because we use it all day every day, the cost is peanuts. It even was when I owned my own shop, It's one of the basic costs-of-doing-business.
4 Likes
What are things you can't do with the HTML version?
1 Like
Come to the open office hours on Thursday. @DaveRamsey will walk you through a lot.
1 Like
This wasn't as how long you have using FileMaker ( as in years or versions ). I was referencing how many hours during a week you use FileMaker, and WHAT you are using it for.
Strictly considering a recent event at our office. I was able to go in and change 450 instances of piece of code to use a modular script we built to handle some common actions. In less than a minute, I had the entire list of every instance of that code, it's context, and some custom flags to tell me specifically which instances of that code I needed to change. Even with the HTML DDR, that would have taken me a couple hours to get all the references and determine which ones needed to be changed.
It only takes saving less than 8 hours in a year, to break even on the FMPerception purchase. Last year alone, it saved me dozens of hours or more.
I could go pull your own comments from other threads, if you need that. But I wasn't making an accusation. As Wim said, it was just friendly push back.
My usage varies week to week along with my postings, I'm sure. Those postings, like the DDR, are just a snapshot. 
Lately, I've been doing much more with FMP -- but FMP is a supporting product for me and my business not a money maker on its own.
1 Like
Understood and noted.
That's also the point I was making. Nothing wrong with it, and I wasn't implying that there was. But how you use FM will also affect what you do with it. What you do with it will affect how much value a tool like FMPerception will give you.
For most people developing in FileMaker on a regular basis, it's worth it's weight... Whether you are building a monolithic system, purely integrations, add-ons, etc, it's just about getting answers to questions. Sometimes those questions are ones you didn't know you needed to ask. One good example is the change to the version function between 18 and 19. There is, or will be, a flag in FMPerception for that, to let you know you may want to check the usage of the function make sure the change in FileMaker didn't break your code.
1 Like
That's fine, thanks J.
Both of those examples I gave above:
- do a quick diff between two versions of the same solution
- create your scripts to do custom reports
plus: - produce a to-do list, keep notes
- import and correlate the top call stats log to quickly pinpoint 'expensive' design choices
- export a subset of the data for external reporting
- ... the list is endless
1 Like
To address @anon45965781’s concerns:
-
Boolean and regex search:
Boolean search is a good one, and for these I will generally use FMPerception to narrow the data and then dump to CSV for FileMaker. There I can create much more elaborate filters... though FileMaker doesn’t support regex searching either. That said, if you want more flexible Boolean searching built in, your current best bet would be one of the FileMaker-based tools.
I get one or two requests for regex search per year, and while it is definitely on the list, there are more things above it on the list that Will be useful to a larger slice of the developer community. I anticipate a future FMPerception that is rebuilt from the ground up to take better advantage of the newer Save as XML. Regex searching will likely be much easier to implement in an app that plans for it from the first line of code. No promises. -
Refactoring: While this is a dream feature for me, the current limitation is in FileMaker itself. FileMaker just doesn’t have the hooks necessary to do that work. There are elements of public statements from Claris that suggest that this may well eventually become possible... and when that happens I’ll be taking a very close look at it. But until then, the only place that you could do something like this is for copy-pastable elements where you hand edit the XML. FMPerception can help you isolate the appropriate chunk of xml for dumping to your preferred XML editor, and then you can paste it into your database. The limitations on where this roundabout process can be applied are not hugely motivating to me, and other tools have handled it quite well, so it hasn’t been a high priority.
I understand that FMPerception is not the tool for you. I don’t think it’s possible for any tool to be the tool for everybody. Unfortunately, even adding these features will probably not tick the box cost/benefit-wise for you. I don’t currently believe that adjusting the FMPerception price to $99 would result in sales volume increasing by 5X... Even if it did, it would increase our support costs by a factor of 5. For users who bill for their FileMaker work, and/or spend most of their day in it, the math works out quite well.
I built the tool that I always wished I had as a FileMaker consultant. I’m sorry that it’s not the tool for you.
9 Likes