It wasn't that long ago that you actually received paper manuals when you purchased new hardware or software. Nowadays everything is a mixture of HTML and PDFs that you can search through when required, but who reads manuals?
Most tech savvy people will happily place user guides to the side when faced with the job of using new software, hooking up a home theater system or assembling their next purchase of flat pack furniture.
Having used FileMaker for the best part of 10 years I feel I've got a strong grasp of my favourite database platform. Imagine my surprise when a recent trip into the Help documentation rewarded me with a new appreciation of the FileMaker find function.
More specifically, while I use the Find function every day I was unaware of the way in which some of the wildcards can be used, particularly when it comes to searching on date fields.
Try a few of these gems.
Search for date values matching a specific month
1
Returns all records within January of the current year (like searching on 1/1/2010..31/1/2010 but much quicker than typing the full date range and doesn't require you to know how many days are in the month you're searching on
1/2009
Returns all records within January of the specified year, in this case 2009
Search for dates values that fall on a particular day
Mon
Searches for all dates that occur on a Monday in the current year
Wed 3/2008
Searches for all dates that occur on a Wednesday within March of 2008
While all of these searches could have been carried out manually or by script these methods are quicker to enter, much more flexible and don't require any additional calculation fields to help provide the required smarts, i.e. an extra calc field that returns the DayName of the stored date.
Further investigation of the help documentation uncovered further gems when searching on time and timestamp values.
Looking for some extra tips? Read the manual :)
Wednesday, February 17, 2010
Sunday, February 7, 2010
All Sorted
Something to keep in mind if you're allowing users to edit and/or create records from within a list or table view is the impact a sort order has on the end-user experience.
A few key points to remember:
1. By default, FileMaker Pro stores and displays records in the order they were added to the file.
2. The Sort function lets the end user rearrange a found set of records, so they can be viewed in a different sequence.
3. The found set of records will remain sorted until a new find request is performed or the records are sorted by different criteria.
This all sounds pretty logical but have you noticed that when you add a new record to a sorted found set, the new record will be displayed in the "correct" position in the sort order as soon as the record is committed?
While this might make sense it can cause confusion for the novice user. Why? Because, as soon as their new record is committed it will move to the correct position in the sort order which might not be visible on screen. This is fine if the user was expecting this to occur, not so fine if they're now puzzled by their "disappearing" record(s).
You should also be aware of this behaviour if you're planning on duplicating a sorted set of records using a loop and the Goto Record [Next] script step or looping through a sorted portal. If the new records are being modified in such a way that they will be "moved" to a position in the list that makes them eligible for duplication you'll find yourself with all sorts of headaches.
Endless loop anyone?
A few key points to remember:
1. By default, FileMaker Pro stores and displays records in the order they were added to the file.
2. The Sort function lets the end user rearrange a found set of records, so they can be viewed in a different sequence.
3. The found set of records will remain sorted until a new find request is performed or the records are sorted by different criteria.
This all sounds pretty logical but have you noticed that when you add a new record to a sorted found set, the new record will be displayed in the "correct" position in the sort order as soon as the record is committed?
While this might make sense it can cause confusion for the novice user. Why? Because, as soon as their new record is committed it will move to the correct position in the sort order which might not be visible on screen. This is fine if the user was expecting this to occur, not so fine if they're now puzzled by their "disappearing" record(s).
You should also be aware of this behaviour if you're planning on duplicating a sorted set of records using a loop and the Goto Record [Next] script step or looping through a sorted portal. If the new records are being modified in such a way that they will be "moved" to a position in the list that makes them eligible for duplication you'll find yourself with all sorts of headaches.
Endless loop anyone?
Subscribe to:
Posts (Atom)
Posts
