Article Tags
Click or tap one of the article tags to filter down to a smaller selection.
- Accounts
- Add-ons
- AI
- Alerts
- Analysis
- APIs
- Apple Maps
- Auto-Enter
- Barcodes
- Base64
- BaseElements Plugin
- bBox
- Breadcrumbs
- Button Bars
- Caching
- Calculations
- Calendars
- Card Windows
- Charting
- Checkboxes
- Code Editing
- Code testing
- Coding
- Color Picker
- Colors
- Conditional Formatting
- Containers
- Context Management
- Cropping
- Crypto
- CSV
- cURL
- Custom Functions
- Custom Menus
- Data API
- Data Capture
- Data processing
- Data structure
- Data Viewer
- Date Ranges
- Dates
- Debugging
- Deployment
- Developer Tools
- Dialog Boxes
- Docker
- Drag-n-Drop
- Drop-down List
- Dropbox
- Duplicates
- Duplicating records
- Encryption
- Error handling
- Events
- Excel
- ExecuteSQL
- Exporting
- External Authentication
- External Files
- Field Formatting
- Field Storage
- Fields
- File IO
- File Management
- File Sharing
- FileMaker Go
- FileMaker Server
- FileMaker Settings
- Filtering
- Find & Replace
- Find Mode
- Found Sets
- Functions
- Fundamentals
- Global Fields
- Global Variables
- Google Forms
- Google Maps
- Google Services
- Graphics
- Grid
- Grouping
- Hierarchies
- Highlighting
- Icons
- Images
- Importing
- Indicators
- Inspector palette
- iOS
- Java/Groovy
- JavaScript
- Join Tables
- JSON
- Key fields
- Layout Design
- Layout Mode
- Layout Parts
- List function
- Logging
- Looping
- Mapping
- Marking Records
- Media Storage
- Menus
- Merge fields
- Messaging
- Microsoft Surface
- Mobile design
- MonkeyBread plug-in
- Multi-key fields
- Multi-option fields
- Naming Conventions
- Navigation
- New Release
- Node-RED
- Notifications
- Oauth
- Object management
- OCR
- OnGestureTap
- OnLayoutKeystroke
- OnObjectKeystroke
- Parsing HTML
- Perform Script on Server
- Performance
- Permissions
- Photo manipulation
- Pickers
- Pivot tables
- Pop-ups
- Popovers
- Portals
- Preferences
- Printing
- Privilege sets
- Product review
- Productivity
- Progress Bars
- PSOS
- Python
- Quick Find
- Record Locking
- Regex
- Relationship Graph
- Reporting
- REST
- Sankey
- Schema
- Script Parameters
- Script Triggers
- Scripting
- ScriptMaster
- SDK
- Searching
- Security
- Separation Model
- Set Variable
- Settings
- Shortcuts
- Sliders
- Snapshot Links
- Sorting
- Spelling
- Spreadsheets
- Startup
- Summary Fields
- SVG
- Syntax
- Syntax Highlighting
- Tab Controls
- Table View
- Tagging
- Terminology
- Text Parsing
- Themes
- Time fields
- Time Savings
- Tips
- Tools
- Transactions
- Tricks
- Twilio
- UI
- Updating
- User Interface
- Validations
- Value Lists
- vCalendar
- Virtual list
- Web Forms
- Web Scraping
- Web Services
- Web Viewers
- Webhooks
- Windows
- XML
Our Library of Videos
Security is one of those funny words. One dictionary definition is "the state of feeling safe, stable, and free from fear or anxiety".
While it may be hard to be completely "free from fear or anxiety" (when it comes to your data), you can certainly lock things down so it's SUPER hard for any "bad guy" to get anything of value.
Questions like "Is FileMaker secure" are pretty general, and given that FileMaker is just a tool, you're the responsible party for making sure things keep you free from that "fear or anxiety".
Since your FileMaker solution will inevitably need to reach out beyond itself, using external services, there are many situations where you need to secure things as much as possible.
In this video, I walk through accounts, passwords and security. Not FileMaker's accounts and passwords mind you - the accounts and passwords of your users and external services. I cover topics related to storing passwords within the database itself and how to go about securing access to external services used by your solution.
If you've not taken the time to learn the difference between a digest hash and encrypted data, and how you might use one versus the other, then watching this video will certainly help you out!
The last time I released a video specifically about merge fields was in 2007.
Wow! That's a long time and it's such a powerful and frequently used feature. What would a database solution be without the ability to send email?
So, here we are with this Karate App solution and we're using the separation model to design and deploy. The next addition to the database is the ability to send email - so, we need merge fields.
Using a few custom functions, an admin layout, the user interface and some merging creativity, we can easily add new fields which can easily be merged into any content. By explaining how this process might work in your own database, you will quickly realize the benefits of integrating this type of system into your own solution!
Nobody likes a rug being yanked out from underneath them - to reference the popular phrase. The same thing applies to your interface and solution. When a user moves from one layout to another, they're typically not expecting to come back to something different than when they left.
The biggest issues with FileMaker retaining layout state are tabs and portals. In the past, I've covered how you can move from one record to another and maintain the selected portal row.
In this video, I present a simple technique for using the ever popular "back button" feature found in pretty much every web browser. The video shows how to not only include this feature, but also how you can return tabs to their previously selected state - and with very simple scripts.
If you've rarely found great uses for FileMaker's script triggers, then this video will provide you with some great information about using them.
For any of the functions referenced, you can find them here.
https://github.com/filemakerstandards/fmpstandards/tree/master/Functions
How is it you know a student from a vendor and a vendor from a teacher? Well, it's all context right? You visit the school to see the teacher and you visit the industrial complex to see the vendor.
As the saying goes, "If life was only that simple." Of course you can find a student at a school OR an industrial complex - the former is every day life and the later is a field trip - Yeah!
Since we can't count on context, we must use something else to identify what's what and who's who. Let's call that thing Data Classification.
Classifying things falls under that wonderful term named taxonomy. It's where you stuff anything you have with the terms which most clearly identifies it
All jokes aside, this isn't a concept which comes easily to the disorganized database developer. There are many ways to classify your data and knowing which one to use, and when, can be the confusing part. Staunch friends of E.F. Codd will tell you to use as many tables as possible and the finish-it-quick demands of an off schedule project will scream "just add another field".
Without having bias towards either of the extremes, I hope this video will provide a good deal of insight into how to approach your own Data Classification needs.
It's SO, and I mean SOOOOOO, easy to cheat on the Data Separation model. You just add a little calculated field here and another over there - it's no big deal right? Actually, (my personal opinion) it's not that big of a deal. I mean "Really" you do have access to the UI file AND the Data file - "You're the developer!".
However, the situation may come up where these "extra" fields just clutter up things when some DBA wants to access the data via ODBC. So why not just keep it clean. The trick with this little problem is, what you show in the UI - for the user - is not what you're going to store in the database. This will happen quite a bit, and requires a different way of thinking than "I'll just add another calculated field."
The answer to this little problem is UI Utility tables. Sometimes, it's as simple as a tiny little table storing the names of days. Other times, it may be a complete mirror table which contains automatically populated data just for the purpose of showing calculated values.
To what extent you carry out the Data Separation model, is entirely dependent upon your willingness to keep things separate. It's my job to show you how you can do this - and that's exactly what this video is all about. The separation of Data Storage versus Data Display.
Here's yet another video in this series which doesn't have much to do with the Separation Model. However, it's a really fun video because it deals with something so perfectly usable that it'd be a crime not to use it within your solution somewhere - barcodes.
You see, humans are prone to error and you can almost always reduce error when you use something the machine can both generate and read.
Barcodes have been one such answer to this "human error" dilemma for many decades. Even the most simple of barcode implementations can save many painful hours of mundane data entry. With a little creativity, I implemented inexpensive student ID badges for easily tracking attendance.
In this video, I discuss my super simple implementation of using barcodes within the KarateApp solution and give you a good deal of information about how you can implement in your own specific ways. With scanners and barcode fonts being both cheap and easy, it's a no-brainer for use in any FileMaker solution!
Reporting is one of the most field hungry things you can ever do within FileMaker. So, what do I mean by field hungry? Well, take your standard timestamp value for example. It's composed of many different pieces of information - many you may want to report on. It has a day name, day value, month name, month value, month number, year number, hours, minutes, seconds and maybe even a time zone.
WOW! That's a lot of extra fields. I count at least ten different additional fields. I'd really hate to add even a portion of these extra fields to any data table which requires them for reporting. It's just a lot of extra "cruft" in my data file.
So what are the options? Well, to give you a hint, you can easily create a "Reporting" file and do everything within that dedicated file. In fact, in many cases this is a very safe and sound solution.
Then again, we have to take into account what our deployment model is. This is really the determining factor of how we're going to report. Is the UI file on the client device or being shared on the server? Do we want to maintain older reports so they can be printed in the future? Are we going to save a PDF version, save the data or simply use the original data? Will the original data change?
What about what's needed in order to print the report? How about security and access? Should all users be able to see, access and print all reports in the system?
These are all questions you'll have to ask of yourself when designing your own system. In this video I give you a ton of solid information about how printing might work in the Data Separation model. Give it a watch!
In this video in the series, we're again laying some groundwork for future videos which deal with "separation issues". The content covered isn't super specified to the Separation Model, but does provide a wealth of knowledge about integrating a vital feature which is inevitably added to most any database - calendar widgets.
Even if your database never deals with scheduling events, you're going to need to filter out information based on dates, times and date/time ranges - if only for reporting purposes.
In order to make this happen, you'll often need some form of a calendar widget. Yeah, FileMaker does provide a great little calendar widget which can be used right on fields - and you may be able to get by with that alone - but really, "Why stop there?". Once you've implemented the calendar widget solution from this video, you may be hard pressed to use any other method. It's universal, it's flexible and quite powerful. Here's a hint, "Use a 'Calendar' utility table." Watch the video for more useful information!
For anyone who has worked with FileMaker for more than few years, the limitations found in the sorting script step are simply "the way it is". You can't dynamically specify either a sort field or the direction based on a calculated value or variable - like you can with the output path of an export for example.
These limitations have always been something to work around and overcome. Over the years, I've used many different methods for sorting. They typically always centered around the script which was used for handling the sort.
It's always been easy to add as much logic as required to a script, but making things as easy as possible and portable has always been the holy grail. I mean really, who wants to keep coming up with a new way to manage sorting list views and portals when you've got a solution to build. This stuff should just be built in.
Of course, part of the fun and appeal of FileMaker is the fact that it's like a puzzle and it always seems to present that worthy little challenge. So consider this video an answer to that challenge.
In this video, you'll learn, and have access to, what I consider to be one of the most elegant ways to managing sorting list views. If having your list views (and portals) provide the same features that every desktop user has grown used, (e.g. sorting columns and indicating direction) then you owe it to yourself to get this one down. It's just way too elegant and way too easy to implement once you've got the basics!
In all likelihood, the only database you'll provide [Full Access] for all users is the database you ONLY use for yourself. Otherwise, we're going to be adding security - plain and simple.
In the Data Separation Model, there's a number of options which all depend on how you're going to deploy. If you're going the low cost route, then using External account authentication, by far the easiest method, is not going to be an option. External authentication requires FileMaker Server and preferably (although not required) a deployment of either Active Directory (Windows) or Open Directory (Macintosh). So, understanding how external authentication compares to using FileMaker's built-in accounts is critical to your deployment strategy. Using the low cost route means you need to get a few things right when using the Separation Model.
In terms of implementation, this will very likely employ the use of a default username and privilege set for the UI file, while the data file retains the collection of usernames and passwords which protects the data.
In this video, I take a fair amount of time to walk through the various settings and areas which you'll need to be familiar with. I discuss what to watch out for, and how the separation model will impact your security. If you've not taken the time to really understand what FileMaker is doing, from a security standpoint, then this video will have some great pointers for a better understanding.