If you purchase a BaseElements Site Licence, you also have access to use BaseElements on multiple machines at the same place of work, as well as on a FileMaker Server machine shared amongst multiple developers. You must have a Site Licence registration code to act as a client to a shared version.

The Site Licence is flexible, in that you can mix and match single user and Sharing enabled versions as you wish. You can use BaseElements on as many computers as you have developers in the same company or at the same site.

Using BaseElements on FileMaker Server

The demo version above has sharing enabled for 2 External Authentication Groups :

FMP_BE_Edit
FMP_BE_Read

that have Edit and Read only access enabled respectively.

At present sharing is only switched on for EA accounts.

The reason for this is that you may want to run BaseElements on a server that is also sharing other files for users not developers. This way you can restrict BaseElements to only those users who have access. A default or published standard FMP account would allow users to bypass the EA account, which may not always been in the best interest of the company.

If you need a specific EA group added to the files, we can do that for you. Contact us for details.

Background

In versions of FileMaker prior to v7, you had one list of "Relationships" for each file and this represented both the end point of the relationship as well as the field being used as a match field. v7 changed all of that where you have a graph, and it now has Table Occurrences as well as Relationships to join them. But a single TO may be connected to one other TO, or to none, or to 100. So the same concepts no longer apply.

Imagine a simple graph where you have 3 tables, A, B and C. They're joined together in that same order by 2 relationships A-B-C.

How do you tell which Relationships are being used? Imagine you have a layout for each one, and that you have a script that references a field in C. If the script is called from a layout that uses C as it's base table, then none of the relationships are used. If the script is called from a layout using B, then the B-C relationship is being used, but the other A-B relationship isn't. And if it's being called from a layout based on A, then both Relationships are used and required.

However scripting is also not that simple any more. Imagine that the script is called from a layout based on A, but does a Go To Layout based on a calculation passed as a script parameter. Which layout does it go to? And so, which Relationships does it use?

The short answer is that there is no way of knowing.

The main difference is that all of the functionality now in v7 and later refers to TOs and not relationships. You no longer know what path a reference to an end point like TOname::Field will use, just that TOname is the end point. And so given a layout based on A and a calculation that references C, you can only assume that it's possible for both Relationships to be used at some point.

So, when are TO's Unreferenced?

If you know, in the example above, that A is not used for any layouts, and not used in any calculations or other steps, then A can be deleted. It's not used anywhere.

However, if B has no layouts and is not referenced anywhere but both A and C are, then you don't know if B is used or not. Again it depends on what context the references to A and C are used, and where and how.

The short answer is that any TO is unreferenced only if there are no explicit references to it, AND it's the end point of a graph. A TO is on the end point of a graph if it only has one or no relationships to it.

Deleting unused Relationships

You can only then remove a Relationship by removing a TO that has relationships to it. So instead of thinking in terms of Relationships, think in terms of TOs and work from there.

All of our Developer Products are available on an unlocked completely un-restricted 30 day trial. We suggest that everyone take advantage of that before purchasing. Because of the nature of that policy, and the fact that you receive an electronic product that cannot be returned, we do not by default offer a refund if you decide the product does not meet your requirements.

However, mistakes in the ordering or other processes do happen, and we're very flexible with people who are willing to be reasonable. If you believe you are due a refund, please contact us and we'll certainly listen.

Ultimately it will be at our discretion as to whether a refund will be offered.

BaseElements requires a minimum of FMP 8.0 to view any of the main layouts. Almost all of the layouts use tabs, introduced in version 8.0, to display multiple portals on a single layout.

However, to use 100% of the functions of BaseElements, you need to have version 8.5 of FMP to run the import process. The import process uses the "List" function, introduced in 8.5 to generate Table Occurrence Groups, and also to locate Script Indirection. It's also used in the Comparison Report to generate lists of layout objects.

I don't have 8.5 yet though !!!

Don't worry all is not lost, you can still take advantage of all of these things by using the Runtime version of BaseElements. Currently the Runtime application is at version 9.0, so you get all of the advantages of 9.0 without having to keep your version of FMP up to date.

You can still generate the DDR using whatever version of FMPA you have, 7.0 through 9.0, and then import into BaseElements using the runtime.

And if you really want to use the fp7 version, remember you can also open the runtime .BAS files directly in any copy of FileMaker Pro or Advanced.

The addition of a Warnings tab to BaseElements also adds the potential for a whole raft of additional changes that we can add to help developers build better solutions.

We're definitely going to be adding these sorts of options to BaseElements over time. The options we're looking at fall into 2 basic categories :

Enforcing development rules

We think that the Warnings feature could be used to enforce developer rules about the solution design. For example, if your development team has rules about field/layout/script naming conventions then this could catch places where that hadn't happened.

Or for example, if your development approach requires every script to be commented to show the function and purpose of the script, then this could also be used to pick up where a script was missing it's comment header.

For example you may decide to enforce the development rules from the guidelines document put out by a FileMaker developer group last year. BaseElements could be used to enforce either some or all of those rules.

Difficult to catch problems

Firstly, we'd like to pick up some of the more difficult warnings. Things like using a Variable before it's been declared in a script - this may assist in picking up typos in variable names.

Others?

There are lots of other potential uses for this we think. We've got some other ideas and we've had plenty of feedback from other people about this too.

But we're still on the lookout for feedback and ideas about how people would like to use this function, and ways that they would like to expand on the offerings already available. Contact us or leave a comment below if there's something you'd like to see.

Version 1.0.5 and later of BaseElements added the option of a "Warnings" tab to detect issues that may or may not be problems in your solution or may just be issues that you'd like to be aware of.

Warnings are different from "Errors" in that an error is an obviously broken function in the database. A warning comes about, not because something is broken, but because it will work exactly as it is setup, but there are obvious reasons why the setup might not be what was intended.

The best way to use the warnings function is to look at this list on the setup, and see which of the errors you want to view and or look at, and turn some on or off depending on your development style. From there you can identify which ones are obvious fixes and should be looked at straight away, and which ones you can leave, and only address if they come up as an issue later.

Below is the explanation and details for each of the items that are currently warnings in BaseElements.

FileMaker Warning Issues

These are issues that are related to the functioning of FileMaker, not the output of the DDR.

Account Empty Password

This means you've setup accounts that have no password. Although not always an error, i.e. the default file option creates an Admin account with no password, in larger solutions with multiple accounts this isn't best practice.

EA Account requires Change Password
EA Account allows Change Password

The External Authentication process doesn't allow the user to change passwords, so trying to enforce the "Must change password on next login" will cause issues, or allowing the user to change the password will also cause problems.

JoinPredicate Field Mismatch

This means that a "Join Predicate" - otherwise known as the lines matching one field to another in a relationship - are not using the same field type. This may or may not be deliberate. For example to match on a non-contiguous list of dates, you'd need to put the list in a text field and match the other side to a date field. However it's often the case that a field match from a text to a number that is done by accident will give unexpected results.

ScriptStep Disabled Errors

This warning is to alert you that a script step that has been disabled but has errors in it. Enabling the script step will cause the broken steps to be active, and this may cause problems, or have unintended consequences.

ScriptStep Modifying Calc Field

This is a simple one to catch, and a good thing to check for. It means you're doing a Cut, Paste, Clear, Set Field, Insert or Replace on a field that is specified as a Calculation or Summary field.

In other words, you're trying to modify a field that can't be modified.

TableAccess Delete No View

This means you have setup privileges in such a way that you can delete records that you can't view. Which means you can't even tell what you'd be deleting when you tried to delete it - which you'd be allowed to do.

Table With no TableOccurrence

Without any TOs for this Table, it is effectively not able to be used anywhere. You could either remove the Table if it's not required, or add some TO's if you plan to use it somewhere.

Table with no Layouts

This may not be an issue and may be deliberate, as you don't need Layouts for all functions, but some functions do require Layouts, and this may cause issues.

ValueList PrimaryField Unindexed
ValueList SecondaryField Unindexed

The Primary Field in a ValueList always needs to be Indexed. This will happen when you first create the Value List. If this isn't the case, the ValueList won't work, and your list will show no data.

However it is possible in some circumstances to have a ValueList using a secondary field that isn't indexed. If your value list is set to "Sort values using : First Field", then the second field doesn't need to be indexed. In fact in that case the second field could be a global or unstored calculation.

However if you sort using the second field, or show only values from the second field, then both fields need to be indexed for the ValueList to work.

Unrelated TOG on Layout

This means you've added a field to a layout where the TO of the field isn't accessible from the TO of the layout. In other words, the field will show on the layout as "Unrelated Table" and won't show any data.

File Reference Points to Itself

This means you've have created a file reference which might be pointing to itself. To get rid of the file reference you need to change all of the objects that use this file reference to refer to the objects directly so this file reference is no longer required.

If this is a different file you may want to consider changing it to a unique name to save confusion.

Sorting from a disconnected TOG

This means you are trying to perform a sort from an unrelated table occurence. You should remove the sort or change it to a different table occurence.

DDR Warning Issues

These are more "Alerts" than warnings. They are to point out issues in the DDR where either the data is incomplete, or there is inaccurate information in the DDR.

ScriptStep XML Fields Missing
ScriptStep XSL Fields Missing

These 2 are related to bugs in the DDR output. In the options for importing and exporting data, there is an option for exporting as XML, and for processing that XML before or after with an XSLT file. You can also set the file to use in both circumstances by a calculation. However any fields, custom functions or other items that are used in that calculation aren't included in the XML output by the DDR.

So in effect a field used only in this place and no other would be listed as "Unreferenced" by BaseElements, when in fact it is in use.

This has been submitted as a bug to FMI, so I expect that it would be fixed in a future version.

ScriptStep GTRR Layout

If you've used FMP in a multi-file solution you may have come across this one. When you do a GTRR script step, but you're using a TO that is based on a Table coming from a different file than the layout, the layout shown in the script doesn't appear correctly.

For example, in a separation of data solution, your GTRR is going to a layout in the current file (the interface file). The TO for that GTRR is in the current file, but the Table that it's based on is in your data file. In this case although the specify dialog will show the correct name, the script itself shows the name incorrectly.

In all of the cases, BaseElements will pick up the correct layout and use that for it's reference. However the data reported in the DDR is affected by the same bug that affects the script display, so it doesn't always show the right information.

As of version 1.0.5 there is the addition of a runtime version of BaseElements that is available for download. This version has also been packaged with a single BindKey that means when there is an updated version available you only need to download the updated files not the entire run-time application.

Background

The FMP runtime process generates the entire runtime application for you. It creates, for example on the Mac, a "BaseElements.app" application, plus it packages all of the DDR files with a special BindKey that links them to the application.

Whichever version that BaseElements is at, the runtime application is at the version number of the copy of FileMaker Pro Advanced that it was generated with. What this means is that if we update BE from 1.0.5 to 1.1.0 for example, but FMPA stays at v8.5 then you don't need to download the entire application again. Just download the updated runtime BaseElements files and replace your existing ones.

Also when FileMaker releases the next update to version 8.5 (presumably to 8.5v2) then we can create a new runtime application that uses the 8.5v2 version as it's engine and automatically take advantage of any fixes or new features in that update. All without updating BaseElements, or without you losing your data files.

How does it work?

If you want to use the runtime, then the first time you download, make sure you grab the full download. Unzip it and copy to wherever you want and use as normal.

When there is an update to FMP or FMPA, we will release a matching BaseElements runtime update for the current release, including a new application download. In this case, you only need to download the application files again, and literally replace your old app files with the new ones. All of your data remains safe.

When there is a BaseElements update, then you only need to download the updated BaseElements files. Move the old "*.BAS" files out of the folder if you want to import your data from them. Copy in the new "*.BAS" files from the download. Once that's done you can import from the old files if you want, or just continue to the use the new files and do a new DDR import..

If you've got any queries, don't hesitate to contact us, we're always happy to help out.

All of these notes apply to version 2.0 and later of BaseElements only.

Separation Model

Now in version 2 of BaseElements, we have separate UI and Data files, so it's possible for us to issue updated UI files and leave the data file intact. Plus we have a button on the setup layout that allows you to manually import from previous versions of BaseElements. So regardless of whether or not there are data changes, it's possible to bring all your data into new versions of BaseElements when changes are made to BE.

To keep track of what changes are made and what sort of import is required, this page will list any requirements and also say whether or not you can just replace the main and UI files.

Instructions

1 - Replace non Data File The BaseElements_2_Data file is unchanged and you can replace the other files ( BaseElements_2 and BaseElements_2_UI ) with the new versions from the download.

2 - Import From Previous There are changes to the data file, and you need to import any data you want to re-use using the button on the setup layout.

3 - Import Again From XML There are changes to the XSLT import process, and you need to re-import your XML files.

Note: This list assumes you're importing from the directly previous version. If you've skipped a particular release, you need to take the greatest action in all the versions in between your current and the new version.

Questions?

I really really need to keep old data : There is no reason that you can't keep the old data by importing into the new files, even if the details above suggest that you re-import from XML. However the reason we list the re-import as the suggested action is that you should be aware that there are differences in the import process, so the data will have changed between versions. Keep the old imports only for historical reasons, and note that any fixes introduced in the latest version won't be included in the old import.

Importing v1 data into v2

The short answer is no, there isn't a way to do this. We changed a lot of the data structure, added more tables that just didn't exist before (Calculations, TORefs, etc), and generally made lots of changes to the field names and methods of working. So there isn't a process to import from your BaseElements 1.x versions into 2.x. There is always the option of keeping 1.x around while you need it, and using 2.x for new imports, or re-importing any historical XML files into 2.x.

This mostly applies to a user on a Mac, as it has floating windows, and on Windows BaseElements starts up maximised.

If you move and arrange the windows as you work, but want to get back to the standard arrangement, there is a script in the "Scripts" menu to do just that on a per file basis. There is also a script in the BaseElements file to re-arrange all of the windows at once.

Moving all the windows at once.

If you move the BaseElements.fp7 window to the new location you want all of the windows to appear, you can then get all of the other windows to move to this location. Just run the script "Set Window Positions Current Window", and all of the windows will be moved to match the top left coordinates of the current window.

What is Indirection?

Indirection in FileMaker refers to the ability to reference an object by it's name, rather than by it's internal id. For example, when you setup a perform script step, and choose a script to perform, FileMaker stores the id of that script you're performing and saves that. That way, you can alter the name, or move the script within your file, and it will always still work. The same applies to fields used in calculations, FileMaker breaks the calculation into it's various parts and keeps all of the field, table, and custom function id's so that you can also rename those without breaking your calculation.

Indirection is when you are not referring to an object directly, you're instead referring to it by it's name. For example you setup a GoToLayout script step that chooses the layout by a calculated name. If your calculation for the name is fixed, but you change the actual layout's name, it will no longer be found and your script step will error.

There are more and more ways in FileMaker these days to use indirection to refer to an object in FileMaker. For example we now have these functions :

GetField ( "fieldname" )
Evaluate ( "myCustomFunction ( tablename::fieldname ) " )

that can refer to fields from a calculation. Also there are things like :

ValueListItems ( Get ( FileName ) ; "ValueListName")

As well as that it's possible to refer to layouts by number and also by calculated name. But these don't have to be simple calculations like the above. They could also be

GetField ( othertable::field )
Evaluate ( $$VariableName )
ValueListItems ( "otherfile" ; $VariableName )

in these cases the actual name to look for is coming from a dynamic location. In short there is nothing that BaseElements could do to work out what that variable is actually referring to at "run-time" when it's in the users hands. There may be cases where it's simple and in theory BE should be able to work it out. But there will be cases where it's impossible to tell, like if the layout name comes from a field that has user entry allowed. BE has no way of knowing what the user will type.

In short it's now possible in FileMaker to refer to objects using this indirection which could mean they show in BE as being unreferenced - if they are also used somewhere else.

Is this a limitation of BaseElements?

No, it's a limitation of any analysis tool whether it uses the DDR for it's data or not. It's a limitation we've now got because of the additional options we've got to use indirection to refer to objects in FileMaker.

I think the indirection options are worth the extra hassle we've added - they give us a lot more options and flexibility for our design choices. For example, you could have one GoToLayout script step in your entire file that goes to every layout it needs via a calculation.

How will I know if my solution is using Indirection?

As of version 1.3.0, BaseElements added a feature to find any examples of where you're using Indirection and alter the way it reports Unreferenced items. This means you can be alerted in advance if an item is Unreferenced, but possibly being referred to elsewhere.

BaseElements uses a simple checkbox to show if an object or item is completely Unreferenced. In version 1.3.0 and later, it also keeps track of whether or not objects are possibly being referred to via Indirection. There are five things that could be referred to Indirectly :

• Custom Functions
• Fields and Table Occurrences
• Layouts
• Scripts
• Value Lists

Custom Functions are found using Evaluate type functions. Fields and TOs are found via Evaluate, GetField and also Field Attribute functions. Layouts can be found via some of the Layout attribute Get functions, and GoToLayout or GTRR script steps. Scripts are found via plugins that can call scripts. And Value Lists are found via ValueListItem functions.

The total list of all of the functions it looks for is one of the setup options on the main DDR layout. So you can pick and choose which functions you want to check for.

How does BaseElements report Indirection?

If an item is Unreferenced, but your file is using Indirection for that item, it will change the look of the checkbox from a check, to a dash. You can still search for these items, as the actual value of the field is still a 1, but there is a calculated image field over the top of the checkbox that shows the dash.

Also the text colour of the totals on the DDR and File layouts has changed. It will change the Unreferenced green count to orange where the item could be referenced using Indirection.

So you can still see, total and search for unreferenced items, but you're now alerted if you should take greater care when deleting these items.

Is there anything else I can do about this?

There is also a function in BaseElements to not count an object as Unreferenced if it uses a specific naming convention. This is the [ ] that are around non deletable accounts or privilege sets. You can name any objects like scripts or other objects with the same conventions and they will not be reported as Unreferenced.

There is also an upcoming item on the todo list to set your own naming conventions for objects that are not Unreferenced. So for example you setup some conditions that say if the layout name ends in "DND", or if it has a "*" in the name, or it's surrounded by [] then it isn't unreferenced, and it won't appear in the totals, or have it's checkbox set.

If you'd like to see BaseElements do something specific, let us know via the comments and we'll do our best to include it.

Are there any other limitations?

First be aware of the limitations in the DDR output. There are 2 significant limitations that you should be aware of. We consider these bugs in the current (8.5v1) version of the DDR output, and have submitted them to FMI as such.

• The DDR doesn't output any information about layout parts. And this includes fields used as sub-summary break fields. This won't catch many people as a field used just for this purpose would also need to be in a sort button or script and BaseElements will reference it there.
• The DDR doesn't include elements used in a calculated XML or XSLT import. This is when doing a script step or button that does an XML import and you choose the "calculation" option from the radio buttons, and use fields in your calculation. There is an easy work around for this that you set your calculation to a variable, then use the variable in the import dialog instead. This is picked up as a warning on the warnings tab - details here.

Second be aware that there are still yet more ways that you can reference items that BaseElements can't catch. Things such as external methods of accessing the database like web publishing or ODBC. And finally that BaseElements can only work with the files you have selected for use in the DDR. Any other files that reference the current one will not be included.