Article Tags

Hide tags

Click or tap one of the article tags to filter down to a smaller selection.

Our Library of Videos

845 videos found.
The Separation Model – Part 7 05/02/2011 - 7:34pm

When I was younger we frequently went camping. This trip felt like we were camping, but I forget if this particular trip was a planned camping trip or just an outing where my Father was helping a friend with chopping up some felled trees due to clearing some land. I remember being so excited about being able to take the small hatchet we had always kept by the fireplace.

I was finally old enough to wield that cool looking ax. The one I had always wanted to snatch up and start swinging around like some crazed arena fighter. Sharp, shiny, hard and heavy, I knew this was a cool tool (especially to boys), and I wanted to use it about as badly as that cool sword shaped letter opener my Grandfather had.

We get to the site, and I start whacking like crazy at the myriad of trunks scattered about the ground. Despite my careless abandon, I remember the incident to this day. My Father was helping out this friend who had not worked with a chainsaw before. While the unknown horrors could be imagined that this friend lost a leg or something worse, it was a bit more mundane, but still a lesson to be learned.

You see, while using a chainsaw, if the tip catches on something, even the log you're sawing, the chainsaw can kick right back into your face. While this was a very minor kickback incident (no injuries this time) and turned out to be a good lesson, I remember it well - as my Father told us both about how to avoid this potential hazard.

Switching over to the world of FileMaker and the design of your database, there are a number of things in your solution which could become hazardous kickbacks - although none that will physically take off a leg. The topic of this video covers one of those potential issues and shows you not only how to avoid the issue, but how to approach your development. You have to think about every action and its consequences.

The current state of the example KarateApp database leaves us with a problem and a solution which will help you in many other similar situations. This video is certainly one worth watching if performance impact is of interest to you!

The Separation Model – Part 6 04/27/2011 - 9:16pm

FileMaker has a few unique features because of it being its own database. Unlike SQL, where you make selections across multiple tables (which FileMaker does support the use of some SQL - via a plugin), there's this concept of multi-keys for the purpose of relating many to many via one single record - or via one single field actually, it's known as a multi-key field.

Knowing about this unique feature, and using it when it makes sense, is something you can take advantage of. So, the trick is knowing the difference between when to use a multi-key relationship versus using an actual join table.

In this part of the series, I showcase how I interrelate a group of people into a grouped family. I do this without using a Join table because the situation is such that the records which relate together are pretty static. Once the relationship is made it's pretty much permanent. I also show you one of the most powerful custom functions you'll ever use when using FileMaker's multi-key feature. It's something you'll use often once you see how useful multi-keys can really be.

The Separation Model – Part 5 04/20/2011 - 8:52pm

There are a lot of reasons to love using web viewers for the purpose of data display. Your data can be presented in a more compact fashion. You can style data in such a way that it looks like it's part of FileMaker. You can add in functionality easily, which may be more difficult using plugins - such as the ability to initiate a VOIP phone call right within the web viewer. Quite simply, a web viewer is always updating and being refreshed - and offers one of the most flexible ways to present data.

The scary part, which really (and I mean REALLY) shouldn't scare you at all, is HTML. If you're creating anything in FileMaker then you simply can't be ignorant about HTML/CSS. Beyond HTML, if you really want to harness some of the true power of a web viewer, then you learn a bit of Javascript and discover all the magic you can do with power tools like jQuery.

In part 5 of this series, I showcase how I use the web viewer to present the data being collected in the Attributes table. I show you how I extract the data and discuss why it's so flexible. While the effort to display in a web viewer may be a bit beyond simply adding a field to a layout, the presentation options is what makes it so appealing. Data displayed within a web viewer can optionally be shown based on access and hiding it is much easier than hiding a field on a FileMaker layout (which can't even be done unless using some sort of portal trick).

The Separation Model – Part 4 04/13/2011 - 4:08pm

It was 2002, and I remember working with FileMaker 5/6 and the concept of the Data Separation model being discussed at the annual FileMaker Developer conference. I remember thinking, back then, that FileMaker just wasn't the tool to even consider this concept - even though you had multiple files for one database. While an avid FileMaker user/developer, I was rapidly becoming familiar with PHP 4 and knew that true separation was similar to what you found in a PHP setup - a backend (mysql), middleware (php) and a frontend (web browser). FileMaker always had to have those "extra" calculations somewhere in order to make your user interface even halfway decent.

Today, however, it's a completely different situation. In fact, I might go so far as to say the Data Separation model should be your first consideration when starting any new FileMaker solution. The reason is pretty simple - it's even more possible today, than ever before, to keep things clean and organzied. There are functions and methods to keep your data file close to 100% clean of extra fields, calcs, scripts and other "extra" stuff that just comes along with developing in FileMaker.

In this video, I showcase how I address one of my own self-imposed problems and also remind myself of the one custom function which, when used with script triggers, can answer a ton of the issues you have when wanting to display things in the interface. This especially applies when you formerly had to add a lot of that "extra" stuff to make your FileMaker solution work the way you want.

If you're missing that one piece of knowledge keeping you from a clean data file, then this video will certainly have what you need!

The Separation Model – Part 3 04/05/2011 - 5:33pm

In this Part 3 about the Separation Model, we head into the actual structure of the data. I start to address the issues you're faced with when trying to keep the data file as clean of "extra stuff" as possible. One REALLY good thing to ALWAYS remember is that adding more stuff to your FileMaker file means more to manage (and re-figure out) later on.

When it comes to using the separation model, you've always got a few things to worry about. The first of which is creating related records. As with all things, there's always more than one way to tackle something. Certainly, you can use FileMaker's default method of adding related records by simply throwing a portal onto the layout and connecting a data table occurrence with another data table occurrence. You could also continuously add fields until your tables have thousands of them (hint, not a good idea).

Within this project, I've opted to use FileMaker's Obligatory Create (yes, it's my own made up term for what FileMaker does). This is in contrast to adding a more generic record creation script within the data file and having that script report the id of the newly created record. The later approach is a method which I first saw at Pause on Error in Portland where the MVC (model/view/controller) was the topic of focus.

Using a Global Transfer method, in conjunction with an Obligatory Create, you gain a number of advantages. You can pre-validate your data, ensure requirements have been fulfilled and apply any data formatting prior to actual storage.

These are the topics discussed in this video, plus anything else related to moving the solution forward. One interesting thing to note is that nothing is permanent within your solution. When you start to investigate the files, try to find where things aren't quite working and see if you can figure out how you would solve them. Hint, the counts for items within the filtered portals on the Edit tab are not functioning properly. They'll need to be fixed.... which is coming up in the next video in this series.

The Separation Model – Part 2 03/28/2011 - 7:57pm

This second video in the series about the Separation Model doesn't exactly talk data strategy quite yet. The tables are there, the files are ready, but in order to start, you need to have a rough idea of what things will look like. How users will start to interact with the data. The first thing to solve is getting the data into the database!

In this video, I talk about the design approach and how I quickly get started on this new solution. I present a number of timesaving tips about working in Layout mode and focus on how conditional formatting is going to be a critical part of developing a separation model based solution.

Using a straightforward approach to your visual design and factoring that into your solution design, you can accomplish a lot of power with FileMaker without a lot of complexity and overhead. One primary example of this is shown in the video. The simple use of the word "Students" is used in every place where it will make immediate sense. This is in contrast to the fact that the data model is using the word "People" to track and manage the data its holding.

Watch this video to grab a number of great tips about using conditional formatting and how you can move ahead with the separation model for your own solutions.

The Separation Model – Part 1 03/28/2011 - 7:54pm

After spending close to two decades working in FileMaker, I'm always amazed there's more to learn. Even to this day, I come up with new ways to utilize FileMaker.

Recently, I started working on a project for a local Karate School. They're just like any other small business, which ends up with a copy of Microsoft Excel and has more needs than the number actual spreadsheets they manage. Of course, we all know that keeping random bits of information in various spreadsheets is just terribly inefficient. So what's a FileMaker developer to do?

Well, this developer just had to solve the problem and use it as a great example to talk about a variety of development techniques and methods. This video is the first video in a series which will focus on the ground-up development of a new FileMaker 11 solution.

Whether you've been working with FileMaker for many years or you're just now getting back into things, this short video series should have a number of things which will help you become a better developer. This first video starts with the benefits of the separation model and how planning a data strategy is a critical step in the whole process.

Portal Navigation Consistency 03/15/2011 - 4:08pm

As with many other development environments, FileMaker offers just enough features to make things happen (and, in the case of FileMaker, a bit more). It's when you use certain features beyond their intended use where you need to get creative.

One such feature are portals. These are primarily for the purpose of showing related data. However, it's just way too appealing to use them for many other things. One of the most common uses is for navigation.

There's a problem, however, when you leave from one record to visit another, via the Go To Related Record script step, the portal resets and causes a disruption in the user interface.

This FileMaker tutorial addresses that issue and focuses on Portal Navigation Consistency.

Solution Updating 03/01/2011 - 2:50pm

Automation is one of the primary keys to reclaiming your valuable time. You're taking it back from any manual process or a system where it requires your direct involvement or supervision.

When it comes to your solution, and the deployment model you pick, you're always going to have to invest some level of effort into releasing a new version. If you're doing this on FileMaker server alone, then the process may be exporting data from an older file and importing into the newer version. This can take many hours of time and also requires some downtime.

Obviously, you can't have users adding new data to the older solution while you take the time to import from a copy into the newer version. So, one potential solution with FileMaker is to use the Client Deployment model, also called the Separation Model. I covered this in the video just previous to this one.

In the Client Deployment scenario, you simply need an automated way to deploy new versions of the client which is used to access the data hosted on the server. This is the topic covered by this video. The method I personally use to update my commercial product the Theme Studio. The concepts discussed in this video apply to both a hosted solution and one which is deployed entirely on the desktop or device.

One thing to note is that getting the new version of a client to a user's device can be handled in many different ways. Via a FileMaker container in the data file, via HTTP, via a web link, via FileMaker's own AutoUpdate or some other creative way.

Hosted Solution Development 02/25/2011 - 7:15pm

FileMaker seems like such an easy software solution. You simply craft your solution and open the file to start hosting it to peers on the same network. If you're wise, you use a copy of FileMaker server and take advantage of backups and server side scripts. This is especially important for your data, right? It's your data that's important. The user interface is simply a representation of that data.

Often, it's only when things start to bog down that attention is paid to performance and making things as optimized as possible. Fortunately, FileMaker client provides a very nice method for connecting to other FileMaker files - via the network.

The method of really taking advantage of client computing power is to put the Interface file there instead of on the server. Users are used to "updating" apps (even more so with the whole App Store thing). By putting the interface file on the client, you gain many advantages. A much faster perceived load time (since you can load any layout which does not show solution data until after a delay) and a number of operations which will run faster.

Your interface file can run as an Advanced stripped file and version enforcement can be managed via a script call to the Data file on FileMaker server. If simply reading this isn't exactly obvious, then watching this video should give you more insight into how the deployment model works.

Pages