Search Project Mgmt
Search FileMaker Blogs

Thank you for visiting the FileMaker Thoughts blog. I recently moved this content over from my blogger account. Hope you like it! When you get a chance, check out the centralized search feature for all the FileMaker blogs found along the right side panel. It is quite handy!


Saturday
Jan242015

The FileMaker LayoutNames Function

From Dwayne Wright PMP, PMI-ACP, CSM
Certified FileMaker Developer

WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright
YOUTUBE: FileMakerThoughts

LayoutNames
LayoutNames(fileName)
All Current Versions Of FileMaker
Returns A Text Result

The LayoutNames function gives you the name of each layout in a particular file. Each layout name is listed and separated by a carriage return. Which means you could save this information as a text file and even import this list into another database. This function has 1 defined parameter, which allows you to pick the file you want the layout names for. You can use the Get(FileName) function to return the current file.

Here’s an example: LayoutNames("Clients.FP7") in one of my databases returns...

Form
List
Report

These are the names of all the layouts in that file.

More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2010 - Dwayne Wright - dwaynewright.com

Thursday
Dec182014

FileMaker Self Relations, Self Joins Or Self Reference

From Dwayne Wright PMP, PMI-ACP, CSM
Certified FileMaker Developer

WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright
YOUTUBE: FileMakerThoughts

Many times we will talk about the parent table and the child table in a relationship. Until this point, we didn’t mention that the parent and child tables in a relationship can be the same table ( although it would take two table occurrences). It is even possible that the parent and child keys are the same field. Just because a relationship is of the self variety, doesn’t mean it can’t also be a relationship of the one to many, many to many, universal or filtered varieties.

Now FileMaker 7 will not allow you to join two table occurrences together twice and that is essentially what you are doing with a self relationship. FileMaker 7 will require you to create a new table occurrence. So a self relationship would probably look something like ... clients ( table occurrence ) linked to clients1 ( table occurrence ). Both table occurrences would reference the same table but you would see them differently any time you are viewing table occurrences for fields, layouts, scripts, value lists and the like.


Here you can see how the “other” file in a relationship is actually the same file as the parent.

An example could be a contacts table that has a type field. You could have a self relationship that uses the aggregate count function to give you a total of other records with this same type in the same table. In this case, the type field would be used as the key field. You would need to setup a second table occurrence to get this to work.

NOTE: This is also called a Self Join Relationship or a Self Referencing Relationship.

=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2007 - Dwayne Wright - dwaynewright.com

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.

Friday
Dec122014

FileMaker Database Design & Information Integrity

From Dwayne Wright PMP, PMI-ACP, CSM
Certified FileMaker Developer

WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright
YOUTUBE: FileMakerThoughts

For most FileMaker solutions, the primary security concern is ...

- keeping the database solution running smoothly
- make sure the data is entered correctly
- make sure it empowers its users to be more productive.

It is quite possible that a security hole can damage the work flow of a database, damage the accuracy of searches & reports and sometimes cause a database to blow up and crash! For example, say that a new user doesn’t really know how to enter information in correctly. So they go to the wrong layout, enter the wrong information in the wrong fields and then the database crashes or the reports are inaccurate.

SECURITY RETURN ON INVESTMENT
Let’s face it, increasing security in a FileMaker solution can become time intensive and sometimes expensive. There is the time it takes to plan, design, implement, document and upkeep a security system. If you skip any of these, your security might be as bad as not having any security at all. There is also the possibility you may need to invest in third party products ( such as plug-ins ) to get the type of security you want.

As we have said before, many FileMaker developers think of security as an after thought, a necessary evil or a type of insurance policy. So it may be helpful to think of what your return is on your investment of securing your FileMaker solution at a particular level. To do this, you may need to identify what business threats are present if your FileMaker solutions security was compromised. This is typically called quantifying risk.

SECURITY POLICIES AND DOCUMENTATION

To most FileMaker developers, there is at least one thing more dreadful than applying security to a FileMaker solution. That would be providing any extensive written documentation about a solution. How important is the documenting the security of a FileMaker solution? A clear policy on what each user can or cannot do with a database solution can be a great aid to a FileMaker developer. Not only in designing or testing the security system of the solution but other productivity related areas as well.

The security policy does not have to be long winded. A security policy does no good if no one reads it because it is too intimidating. Short, sweet and to the point is generally the best method here.

It may help to think of your FileMaker users grouped into individual business units such as sales, marketing, shipping, etc... , which each having a policy of what they can and cannot do within the FileMaker solution. You can also add sub groups to these business units to define security levels by manager, supervisor or data entry person.

A policy also has the benefit of telling your database users what is expected of them.
This can be as helpful as anything a developer can do. If the database or the developer tells a user they should not be somewhere may not carry as much weight as it does in written form coming from their direct supervisor.

While you are at it, you might want to write a policy for the administrators that are in charge of supporting a FileMaker solution. This can be a policy about how the solution can be supported against possible security threats in the future. This can include checking audit logs, sign in logs, user history and other possible security implementations.

We realize this may not be enough information about security policies but do not let that upset you. There are a number of books about the subject which you can find in your local Borders, Barnes & Nobel or at Amazon.com.

=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2008 - Dwayne Wright - dwaynewright.com

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.

Thursday
Dec112014

The FileMaker Many To Many Relationship

From Dwayne Wright PMP, PMI-ACP, CSM
Certified FileMaker Developer

WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright
YOUTUBE: FileMakerThoughts

In a many to many relationship a collection of records in one table occurrence can share a relationship to many records in another table occurrence. Here I have a couple illustrations that might help.

EXAMPLE - A car mechanic may have worked on many cars and a car may have been worked on by many mechanics. So if you wanted all the cars a mechanic has worked on and all the mechanics that have worked on all those cars, you might have an impressive list.

EXAMPLE - A movie may have many actors and each actor may have been in many movies. So if you wanted a list of all the actors in a movie and then a list of all the movies those actors had been in, you would probably have a large list.

EXAMPLE - A high school teacher may have many students and each student may have many teachers. So if said you wanted to find all the students for a particular teacher and all of their associated teachers ... you would get a very big list.

As you may have guessed, this many to many relationships can get complicated. So documentation of the database structure is a very good idea here. If done properly, data is linked from one file to the next. If done improperly, then you may have records that are islands to themselves.

In the past, many to many relationships were done via a multiple line key field on both sides of the relationship. FileMaker has opened the door for many other variations of many to many relationships. We have separate discussions that go into depth about this but I want to at least introduce some of those now. In FileMaker, you can have relationships with a collection of new comparison operators besides equal to ( = ). So, for example, two entities can relate to each other on a greater than or less than setting. FileMaker also supports indirect or flow through relationships, so two entities can see each other through other relationship settings to other entities.

Here you can see how many records can related to many records.
=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2007 - Dwayne Wright - dwaynewright.com

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.

Saturday
Dec062014

The FileMaker Get(PrivilegeSetName) Function

From Dwayne Wright PMP, PMI-ACP, CSM
Certified FileMaker Developer

WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright
YOUTUBE: FileMakerThoughts

Get(PrivilegeSetName)
FMP Version: FileMaker 7
Returns A Text Result

The privilege set is used in concert with account settings to set access levels to a FileMaker database. You have to understand privilege sets to work with FileMakers security environment. Each account has only privilege set. A privilege set can be assigned to multiple accounts. Privilege Sets consist of a large number of security settings ( much like a large lunch buffet ) and the combination of selected options define what a user can do. Privilege Sets can be used to control access to data structure elements ( like layouts or ScriptMaker access ) and/or control access to data within the database file ( a particular field or a particular record ).

The Get(PrivilegeSetName) function will return the name of the privilege set in use by the current database user.

If you run a script with the "full access" check box selected, it will always return the full access privilege set (and it's associated extended privs) during the scripts execution. Any script with the Get(PrivilegeSetName) within it and is running under full access checkbox is useless.

© 2010 - Dwayne Wright - dwaynewright.com
The material on this document is offered AS IS. FileMaker Pro is the registered trademark of FileMaker Inc.