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!


Monday
Oct202014

FileMaker's Allow User Abort Script Step

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

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

This is one of the more important script steps in regards to running a script in a highly controlled manner. The Allow User Abort script step either allows or does not allow the end user to cancel out of a script that is current running.


During the development process, you will likely want to allow the ability to abort a script. During the times of regular operation, there are times that the integrity of the database can be damaged if a script is not allowed to run it's complete course.

FileMaker has a keyboard shortcut for both Macintosh and Windows machines to get you out of a running script. Depending on what happens if a script gets terminated sometime after it started, this step allows you to control if the end user can or cannot cancel the running script.

There are also scripts that pause for user interaction, like entering in key data before the remainder of a script runs. It’s possible that the integrity of the information within the database might be harmed is the script is not allowed to fully carry out it’s task.

FYI... If you have a long script that you will not allow the user to exit from, warn them first. The best way to do this is using another FileMaker script step called Show Message. You can warn the user that the script may take a long time to run and allow them to abort it's execution BEFORE it gets started.

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

Wednesday
Oct152014

Introducing FileMaker Field Data Validation

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

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

How would you like to have a data entry monitor? Wouldn't it be convenient to have an invisible assistant barking at any person entering data in a problematic way? If this sounds too good to be true (aside from a barking assistant) keep reading. I will discuss how you can actually setup up your FileMaker database to perform a data "quality-control" function. How? The key word is: Validation! A well implemented and designed validation scheme can help in searches, sorts, indexing, relationship setting and reporting. When data is uniform, it is easier to use and understand. In addition, it is much more efficient to set up validation options in the beginning and ensure clean data than it is to clean up hundreds or thousands of records after the fact.

On the flip side, you do need to think about your validation settings before implementing them. If you don’t know all the possible data entry variations that need to go into a field, you might validate yourself out of getting key data. For example, what if you setup a “order shipped” field to only allow “yes” or “no” data. What would you enter in if the order partially shipped?

FileMaker validation options are accessed via the field options in the Fields tab of the Define Database dialog box. Validation can be used for Text, Number, Date, Time, TimeStamp and Container fields. Validation is one of the three choices of field options available. The other options are Auto Enter ( when data is entered or edited ) and the other is Storage ( global and indexing options ).

When data is entered into a field with validation options set, if the data conforms to the validation settings, nothing will happen. This is a good thing. However, if the data entered in an unacceptable format, FileMaker beeps at the person doing the data entry. Yes, it is good for you, but can be frustrating for them. You can choose (when the validation fails) to have the user be presented with a default dialog box or your own custom warning dialog box. You can also decide if the user can override the validation setting. By default, it is set to allow a user to override, so be sure to that option is set according to your validation needs!

The set of options available in the validation dialog box are meant to be used together, but you can select them exclusively if you prefer.

In Conclusion - Validation, used properly, can make your FileMaker database become ruthlessly clean and concise. Validation used improperly can really burden your users and become a major roadblock to one of the major purposes of a database ... to gather information!

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

Tuesday
Oct142014

FileMaker Record Locking, Not Security Related

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

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

There is a condition that will look like a security operation but it is not. It is a normal database action to insure data integrity of the database records.

When a FileMaker database is being hosted over a network, only one user can modify the same record at one time. If you try to modify a record that another FileMaker user is currently browsing or editing, you will get a message telling you that modifications cannot be done. The dialog box will also provide the name of the user that is on that record. This is how databases protect themselves from editing conflicts. Another term for record locking is concurrency.

By the way, another user can mean you, my friend. Yes, it is possible to lock yourself out of a record. FileMaker has be ability to have multiple windows open and it is quite possible both windows are on the same record. So it is possible for you to lock the record in one window and thereby be refused to modify that record in the other window. So it is possible to experience record locking in single user mode.

Here you can see the error dialog I experienced when locking myself out of a record via multiple windows.

Monday
Oct132014

Validating Unique Values In FileMaker

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

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

The unique setting in the validation dialog box is designed to prevent duplicate values in a field for all the records in a table. The Unique validation option ignores capitalization, ignores word order (to an extent) and ignores punctuation options (again, to an extent). For example, if you have the word Dwayne Wright and you want to make sure it is validated as a unique occurrence in a particular field in a particular database, then the following is true about validation

Original text Dwayne Wright

versus a second record with the entered values of

dwayne wright - unique validation will fail and FileMaker will bark at you
wright dwayne - unique validation will fail and FileMaker will bark at you
Dwayne - Wright - unique validation will fail and FileMaker will bark at you
wright, dwayne - unique validation will pass, FileMaker will consider this a unique value

As with most validation settings, you need to make sure you have the user override set properly to your needs. If you do not allow the user to override validation, make sure you allow a user a method to communicate any problems this validation setting may cause.

I've seen and heard many developers say that the most common use for unique validation setting is to make sure a primary relationship key (that binds two or more tables together) is unique. I would disagree with this statement because in most cases, you wouldn't have users entering data into your primary key field. Most primary key fields should be auto entered, more than likely never be on a layout a user can see and never allow the user to edit it.

I would argue that the most common use of this validation is the cases where you want a user to do a search for a record before entering a new one. For example, let us say that John "Ripper" Reid is ordering a new widget from us. The data entry person skips looking for an existing customer record and starts entering a new one. When the user enters in the name, FileMaker's unique validation barks are the user saying there is a unique validation problem.

Now here is where it can get interesting.

You can setup a FileMaker layout so the user has to commit to new records and edit record changes. So you can now have the user back out of entering the new record for John "Ripper" Reid. The user then can do a find for John "Ripper" Reid in the table. The user finds the record and decides if that John "Ripper" Reid is the same one as the John "Ripper" Reid that is placing the new order. If they are the same person, the user adds the new order using the found record. If they are NOT the same person, the user enters in the new record, overrides the validation ( if they can ) and then enters in the new order. If the user cannot override the validation, the user will need to enter in a variation of John "Ripper" Reid such as J. "Ripper" Reid, so the unique validation will not fail.

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

Sunday
Oct122014

About Flat File Databases

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

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

Many of us remember when FileMaker was considered a flat file database. This was way back in FileMaker Pro 2.0 days. The description of a flat file database is that all the information a database table ... needs to be stored within that table. You could have information in many tables in a flat file system and when one table needs information found in another table, a lookup needed to take place. This would mean that information was copied from the remote table and placed in the current table so the current table can have access to it.

Flat file FileMaker database design is still very popular to this day. The users are likely using a copy of FileMaker that does have relational capabilities, the users simply designed it in a flat file method. There are times and places where it has an advantage over the relational model. In fact, a flat file database resembles how a spreadsheet works and most folks learn spreadsheet design before they learn database design.

Relational databases are different in that they can use data that is not stored within the table. It uses a key field in both files to setup a common link or relationship. When the data in the key fields on both sides match, the first file can see the data in the other file ... just like if it was stored internally. A relational database relationship has a number of advantages over flat file relationships and I’ll list a few of these below.

- In relational design, when data is changed in the remote table, the parent table immediately sees it. In a flat file, the information would need to be copied over to the parent table again ( normally called a relookup). So a lookup / copy action needs to be performed before data in another table can be accessed.

- Remember that the lookup that a flat file database use copied data when the lookup is last triggered. Relational database can saves space on the hard drive because the data is not redundant in both tables.

- You can make the relationship dynamic. That is to say that if the user changes information in a field, the whole relationship could be changed and different data displayed in a totally different format.

- You can organize your FileMaker solution better by creating an individual table for each major business unit or event.

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

© 2009 - 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.