Merged Import Modification Tracking

[FileMaker Magazine]

No Access? Watch the preview video here. MergedImportTracking_Pre.mp4

Attachment	Size
MergedImportModificationTracking.zip	267.8 KB

By Matt Petrowsky

When developing within FileMaker, there are often times when I'm surprised at how much "figuring out" is required to solve a problem. In this video article I provide a great deal of information about a problem I was having with managing a recurring import of some inventory data.

The data being imported was constantly changing and came from an external source where only a few fields are controlled by the user. With the original FileMaker system, it was structured in such a way where the "clean slate" approach was taken.

The "clean slate" approach, which you can likely guess, is one in which you simply wipe all previous data and simply import a whole new set. While this works well with small record sets, the more you import, and the larger the data set, the more of an impact, in terms of waiting time, you'll feel. You also lose the benefits of being able to assign your own internal key values and maintaining those within the schema.

So, what's the answer to the question of a recurring import where a significant percentage of data may not change? It's record modification tracking. You need to track which records were modified in order to know which should be post processed or updated by the logic of your solution.

This video and the sample file demonstrates exactly how I approached the problem and includes valuable information which I am sure will make you a better FileMaker developer. If you've never understood why you might want to use a "hash" for comparing data, or if you've thought you should really look into performing scripts on the server side then, by all means, jump into this video. It has a ton of great stuff to learn from!

Tags: 

• Importing

View the full article