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!


Tuesday
Mar242015

Why FileMaker Solutions Are Sometimes Not Secure

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

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

As hard as it may be to say, the primary reason that a FileMaker solution may not be secure is the lack of knowledge of the database designer, a lack of respect for the need for security within the solution or the lack of time to plan / test / implement into the solution. FileMaker has an excellant core set of security related features but the developer needs to be able to effectively leverage them for the solution needs.

The person that develops a FileMaker solution may also be the owner, the administrative person, the technical support person or a combination thereof. They may want to put in the best security possible but it is just not humanly possible under the current available time or money resources.

To put it in a nutshell, security can get in the way of the productive use of day to day business. It is quite possible that some poorly implemented security procedures can cause more problems than a security breach ever would. Many times, it takes the occurrence of the worst case scenario before security becomes a recognized priority.

Traditionally, the FileMaker developer, is responsible to take all reasonable steps for designing the security of the FileMaker based system. If the FileMaker developer has to do it alone, they have less of a chance to be successful. To have a very secure solution, you will need to have the support of the application program, workplace supervisors, fellow employees and a host of FileMaker resource documentation.

In some cases, the FileMaker developer may not be the most experienced with how a particular business works. It is a very good idea for the Business Manager to be involved in the planning / testing / implementation of security related features.

=
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.

Tuesday
Mar242015

The FieldType FileMaker Function

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

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

FieldType
FieldType( fileName ; fieldName)
All Current Versions Of FileMaker
Returns A Text Result

The FieldType design function is used to a return information about a field that you might find in the Define Fields dialog box. This is one of those design functions that returns multiple pieces of information separated by a space character. In the case of the field type function, it will return four different pieces of information. So it looks something like,

this field has
aboutThis1 (space) aboutThis2 (space) aboutThis3 (space) aboutThis4

aboutThis1 - tells you something about the storage of the field such as if it is a global, summary, unstored calculation, stored calculation or just regular.

aboutThis2 - tells you the type of field such as text, number, date, time, timestamp or container. It does not tell you if the field is a calculation field because that is told you in aboutThis1. However, it will tell you if the calculation result itself is set to text, number, date, time, timestamp or container.

aboutThis3 - is about indexing and returns that it is not indexed (unindexed) or is indeed indexed.

aboutThis4 - returns the number of repetitions for the field evaluated.

FYI...
The fieldname parameter has to have the name of the field entered in within quote marks.

So here are some examples I pulled right from my article database...
FieldType ( Get ( FileName ) ; "Blog" )
Standard Text Indexed 1

FieldType ( Get ( FileName ) ; "Blog Title Calc" )
StoredCalc Text Unindexed 1

FieldType ( Get ( FileName ) ; "g_examplehypertextcalc" )
UnstoredCalc Text Unindexed 1

FieldType ( Get ( FileName ) ; "blog_IMAGES::linked images" )
Standard Container Unindexed 10

In the last example, I’m looking at a related field. So I need to add the name of the related table occurrence in the parameter "blog_IMAGES::linked images".

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

Monday
Mar232015

Normal In The Second

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

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

To be in compliance in second normal form, from one record to the next, very few of the fields in the table should have the same exact information. For example, let us say we have a technical support call logging database that has the following fields...

Customer Name
Customer Address
Customer City
Customer State
Customer Zip
Support Call Title
Support Call Date
Support Call Comments
Tech Support Employee Name
Tech Support Employee Department
Tech Support Employee Phone Number

This database will work and can be used to log technical support calls from customers. This would be what you call a flat file database and could even be logged in a spreadsheet. You might laugh but you would be surprised how often spreadsheets are used this way.

Although the above database would work, it will show significant stress when you start adding a lot of records or users to it. Say we have 1,000 logged support calls in the above database. How many times is the customer information or the employee information going to be duplicated? Quite a bit to be sure and think about how much time was wasted entering in this redundant information!

Here is a look at the same information in 3 database files that conforms to the second rule of normalization. You will see that customer and technical support information does not have to be duplicated when new support call transactions are logged. Searches and reports can be done quite a bit easier as well.

Customer Table - ( primary key field - customer id ), Customer Name, Customer Address, Customer City, Customer State, Customer Zip

Employee Table - ( primary key field - employee id ), Tech Support Employee Name, Tech Support Employee Department , Tech Support Employee Phone Number

Support Call Table - ( primary key field - support id ), ( child / foreign key field - customer id ), ( child / foreign key field - employee id ), Support Call Title, Support Call Date, Support Call Comments

FYI ... In some cases, second normal form can be more of a pain than a pleasure. One example can be exporting information, trying to gather all the related data can be a pain. You might find out that you complied with second normal form in your design but a business need required you to undo ... the good thing you did. Other examples could be showing data on a PDA, showing data on a web site, exporting the data to Excel or printing out a directory.

=
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.

Monday
Mar232015

FileMaker Validation Using An Existing Value

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

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

The validation based upon an existing value option is the opposite of the unique value validation option. In this case, you want to make sure that the data within a given field for any newly created or edited records can be grouped by that data with other existing records.

You can probably see where I’m going here. Validation of this type is very helpful in reports that group data. I have literally seen the following variations of user data entry for payment terms of 30 days ...

Net 30
Net 30 Days
30 Net
30 Days
2% 10 - Net 30

Granted the last one is a bit of a stretch and I don’t know of many companies still doing a 2% discount if paid within 10 days. But you see where I’m coming from. A report would look at all these values as unique data but the “information” is the same.

This is a great way to point out the difference between data and information. Data being source material and information is its intended meaning.

Typically, your best option for consistent data entry is the value list. There are still some possible issues you might have in using a value list in every situation. For example, you will do this with a pull down menu but then you can't tab into the field. A pop down list allows you to type in unique values if necessary and that may be fine in some situations.

Of course, another option is the auto enter based on previously entered values, also known as type ahead. In any case, validate existing value can be a great aid in data integrity along side of any of the auto enter options you employ.

Along with setting up validation, you may also want to consider how you communicate with the user when validation fails. FileMaker does have it’s default dialog box that comes up when validation fails. FileMaker also provides a method to provide a custom dialog box for this event as well. Overall, the “out of the box” validation failure message will likely be a bit vague for the casual user.

=
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.

Thursday
Mar192015

Normal In The First

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

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

Remember when we chatted about relational database inventor E. F. Codd’s rules of normalization? Now is the time to fill you in on the specifics. For a database to comply with first normal form standards, a field must only contain only one value. So let me illustrate where you cannot break the first normal form in FileMaker ...

A number field in one record cannot contain 167 and 155
A date field in one record cannot contain 10/25/2002 and 11/25/2002

If you try to do this in the number field, you get 167155, which isn’t 167 or 155. You can only have one number value in a number field. If you try to do the date field example, FileMaker will bark at you ( via a dialog box ) saying that the data string cannot be recognized as a date. So you see that you can only have one value in number, date and time fields.

NOTE: The one exception to this in FileMaker is repeating fields. Repeating fields can be used to stored more than one number or date in a field. This can be used to your advantage when you want to break the rules of normalization ... for a really cool technique.

You can and perhaps often do have multiple values in text fields and break the rule of first normal form. Let’s take a look at an example ...

A text field in one record contains 916 N. Vermilion, Danville IL 61832.

Here we have multiple address values in one field. You might think we have one value, an address. Most database professionals would see four values, street address, city address, state address and zip code address.

If I were to do a find in the above field for 916, I very well make get a found set of records where the zip code contains something such as 916XX. If we break that information into separate fields, we won’t find zip code matches when searching for street address information.

A more common violation of first normal form is the name field instead of the first name and last name fields. Here also you could have a field that contains the data string of Bob Smith and Loraine Bobbett. If you were to search for “Bob”, you search would find both records. If you had a separate field for first name data and last name data, your searches will be more accurate. Now if you have a number of fields that violate the rule of first normal form, you will want to parse the information into multiple fields.

=
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.