To make that easier I keep my DDRs in folders where it's easy to go back to older versions and locate them. If I want to do something like run a comparison report, then I re-import from the old DDRs into the latest version of BE. This works because you can run two copies of BE at the same time with no issue.

In situations where I want to look back at an older version of a solution Analysis, I open up my old copy of BE and just compare visually.

I just keep older versions of BE, I move them to an archive folder and I start fresh with the new version of BE. So I want to outline how I work with BE to not have to do data migrations. And I don't ever want you to not trust the data in BE. If I support a method to import data from old versions of BE into newer versions of BE then I'm supporting an approach that means you will have inaccurate data. One of the critical things that we've always tried to do is to make sure BE is super accurate. In the new version of BE we do, and so the two versions of your Analysis will be based on different interpretations of the data and one of them won't be accurate. In the old import we didn't have this new feature. So assuming you 'update' BE, unless you re-import from the DDR then you won't have accurate information in one Analysis, compared to a new one. And a new version of BE will add new functionality where it pulls data from the DDR in a new way. The data in BE is produced from the data in the Database Design Report. And if you've worked in any way with data inside FileMaker files, there's no 'simple' way to update a solution, although new tools ( data migration etc ) do help.īut on top of that, BaseElements has another unique issue that makes this a bit different.

About how BaseElements worksįirst as you can probably tell, BaseElements is just generic FileMaker files. If either of these functions (or both) are present in one of the relevant items, the dot will appear in the ExecuteSQL() column.A common question with BaseElements and new releases is 'How do I update to a new version of BaseElements'. The ExecuteSQL() column is configured to look for ExecuteSQL, and for a custom function called from the FileMaker SQL Sugar collection of custom functions. The default settings have an example of this. This is really helpful for when you might be using a custom function to do ExecuteSQL. You can setup each column to look for more than one function. If you change the Flagged Functions preferences again, you just need to save, and refresh (or reload) again. The two ways to do that are to either hit File->Refresh (which will tell FMPerception to clear its memory of the previous data and load it anew from the source DDR files), or make a new DDR Browser window and point it at a DDR. Because FMPerception caches its query results, once it has determined how to display a list of, say, Fields, it will not recalculate the results of that query until you tell it to dump the old results. Either hit Refresh, or load a new DDR.There are 2 things you must do to see your preference changes reflected in FMPerception's flagged functions columns: Once they are defined they will show up on the list view as described above. You can change what functions these columns are looking for in the application Preferences. For example:Īvailable in the list view on the following objects: Since 'Get' isn't specific, you need to use the part that is inside the parens. You just need the whole name, not any of the parens, or parameters. See the Interesting Note below Video Feature Details Įxact Match is required for function names. You can even set them up to search for more then one function, and combine the results into a single flag. It's exactly the kind of thing you want to keep an eye out for. For example, one of the default columns is setup for tracking Evaluate(), which can be slow, and fragile.

These are great for keeping track of where you are using functions that may need special care, or are potential performance issues. Flagged Functions are functions that you have indicated that you would like to be notified about when looking at fields, scripts, script steps, layouts, layout objects, and custom functions in the results list.

Compare fmperception to baseelements