Hi - not sure if this is the right place for this post, but I bet Lee will move it if it isn't.

 

I'm trying to do a better job with annotating, documenting and organizing my database model.  Trying to figure out the best way to document the reason for various table occurrence combinations, why a script is called, purpose for complex auto enter calculations, etc. I'm finding that I did things a couple years ago to get around particular quirks and deficiencies in FMP (like row highlighting before conditional formatting existed), and now I have to go back and retrace what I was doing.  

 

FMP's built in features don't allow too much flexibility for this.

 

I've considered modelling the database in a tool like MySQL Workbench or Astah - not for the purpose of actually connecting those models to anything - but purely for documentation.

 

I wondered what others do in this regard?  What are best practices for documenting why and how the database is set up?

 

Thanks!

Michael

Before I move it.

This topic is for the discussion of the special tools that are part of the Advance edition of FileMaker.

 

Let’s clear up what it is your are needing. IIUC, you are looking for ways to document your files. If so,  perhaps these sites will help, FileMaker Standards Organization , Github, and  FMDev PDF on Conventions 

I'm familiar with the links/resources you suggested.  What I'm looking for are recommendations about tools to document my solution - rather than standards and best practices.  I've found the  annotation possible in the relationship graph is rather limited.  So I'm wondering if other developers use any additional tools to model/illustrate/plan or document their solutions.

Well base elements is the plugin/application you migh be after, I am test driving it myself at the moment.

BaseElements all day, every day.

 

As to the graph: what would you want to see added there?  You can add stickie-like notes, use colors,... I don't think I ever had the need to do more there.

Hi Michael,

 

Besides tools like BaseElements and Inspector Pro, maybe you had something  like this post by DARREN here in mind. 

@Lee: that is a good post. But...

@ Wim: I don't think the sticky notes are sufficient at all. For one thing, they don't stick to table occurrences. I want to be able to store a comment INSIDE a TO, so I can remember why I added it, and where it's used. And/or store comments inside the relationships.

 

There's also no way to document the underlying tables. One approach to that is to create a dummy global documentation field and put table info in the field's comments. You could alternatively use the table's primary key field comments.

 

It would also be nice if layouts could be documented as part of the layout setup. But at least now we can put comments off to the right in the non-visible area.

 

@MSPJ: I don't see much of an issue with documenting calculations and scripts, since both accommodate comments. The tools you want for analysis are either BaseElements or InspectorPro. You can use either as a starting point for annotating every element of your files.

I want to be able to store a comment INSIDE a TO, so I can remember why I added it, and where it's used. And/or store comments inside the relationships.

 

There's also no way to document the underlying tables. One approach to that is to create a dummy global documentation field and put table info in the field's comments. You could alternatively use the table's primary key field comments.

 

It would also be nice if layouts could be documented as part of the layout setup. But at least now we can put comments off to the right in the non-visible area.

 

 

I hear ya.  But there is something to be said for NOT storing that with the schema but documenting that elsewhere.  I certainly would not want to take to trip to the graph every time I want to know why a TO was there, or a table, or a field, or a layout.

 

That's why we keep data dictionaries outside of FM: we can consult those from wherever we are without having to back out of layout design and into table schema design...

HI all - thanks for all the suggestions.  I do have Base Elements actually - and perhaps I should try to use it more for this purpose.  I'll have to look into that more.  What I've more or less settled on is Visio.  I'm doing a high level relationship graph in Visio.  The nice thing is there are all kinds of ways to lock comments to graph elements, call outs, containers that stay with whatever elements you put them in.  Notes that can be visible or not visible.  And I can use different sheets to focus on particular table occurrence sections for different purposes.  It's a bit of re-work, but not that much since I'm not doing all the fields or calculations, etc there - just the high level view, key relationships, etc. 

 

Even if BE allows similar, I like doing it in Visio because of the obvious visual connections.