Meta-Consulting
Meta-consulting is a service Database Pros offers to help other developers
over programming hurdles via GoToMeeting. Email John Mark Osborne or call John Mark at (909) 393-4664 to find out more about this service.
Recovering Files For some reason, many FileMaker developers think you can recover a file and continue using it. Well, you can if you want to live your life dangerously. Recover is a great tool when used properly. The proper use of the Recover feature is to recover a file and then import the recovered data into a backup of the file which is not damaged. In other words, the Recover feature is for recovering your data not your schema. Even with the new recovery features in FileMaker 10, always remember that FileMaker assumes you are recovering a file because you have no other choice. Therefore, the Recover feature will remove any suspect scripts, fields, layouts and other features it believes could be causing the problem. While the Recover feature could completely fix your file, it's also possible it may not remove all corruption even though the file appears to be functioning properly.
For more information on recovery, see the white paper titled "Demystifying FIleMaker Pro File Recovery" by Steven Blackwell, available in the Resources area of the Database Pros web site.
Dull Boy FileMaker files were stored in clear text prior to FileMaker 7 so, if you opened a FileMaker file in a text editor, you could see the phrase "All work and no play makes Jack a dull boy" in the header repeated over and over. No, it's not a virus! My understanding is the developers just needed to take up some space in the header and that's what they came up with. Today, modern FileMaker files are stored in Unicode so I'm not sure if the phrase is still there.
Window locking is akin to record locking and is considered the same error when it comes to the Script Debugger (301). Essentially they are the same except that window locking doesn't require the FileMaker solution to be hosted on a server to reek havoc with scripting and manual editing of records. In other words, window locking is record locking in a single-user scenario but only on the same record. It has nothing to do with multiple users.
Demonstrating Window Locking Window locking might be best demonstrated using a simple example of Companies and Contacts. Imagine you have a table of companies with multiple contacts for each company.
With a simple one-to-many relationship, you can add multiple contacts to a single company record using a portal.
The focus of this article is that simple little button in the portal that goes to the related record.
Every programmer does it but do they ever consider window locking? Sure, record locking is a big thing but what about what happens when the record is being edited in the portal and then the GTRR button is clicked? Try it and you'll find you can can't edit the record in the resulting window. That's because you can't edit the same record in two different windows, even in single-user mode, no matter what type of window is displayed. Document, Floating, Dialog and Card windows will all lock the record if it's being edited in the parent window in the portal.
First Thoughts Your first thought might be to commit the record using the Commit Record/Request script step before performing the Go to Related Record step. That'll work fine on the first related record in the portal but if you click the button in any other row, it's always going to go to the first record. Even though committing the record releases the lock, it also deselects the current portal row. Therefore, the GTRR step simply goes to the first related record displaying in the portal.
My First Time The first time I tried to solve this problem, I continued to use the Go to Related Record step but tracked the window names with a script variable and the Get(WindowName) function. It worked fine but the script was obtuse, there was some flashing going back and forth between the two windows (even with the Freeze Window script step) and it didn't work with the Card type window. I had to go to the related record, reselect the original window with the Select Window script step, commit the record and finally reselect the new window. It was a crazy script that I quickly discarded.
FYI: A Card Window is attached to the parent such that they move together. Therefore, the parent window cannot be selected or referenced. The same is trued for the Dialog type window since it is locked on top of the parent. The child window can be moved but the parent cannot be selected.
A Better Way I knew there had to be a better way but my brain was fixated on the Go to Related Record script step. Once I thought outside the box, the solution was so simple. All you have to do is set a variable to the related record primary key, commit the record, open a new window and perform a find. Error capturing is even needed because you know you are going to find that primary key in the related table. It's that simple.
FYI: I would still use the GTRR script step whenever possible since it's easier to implement with just a single script step.
Additional Thoughts This find technique is also useful when you don't have a portal or relationship already made. Just as the ExecuteSQL function was designed to unclutter the Manage Database dialog from single purpose relationships, so can this find method serve the same purpose. In my long development career, I have found there is usually a relationship already available but if you find yourself in a situation where you are creating a relationship for a single feature, consider both of these methods.
Alternatives There are always alternative methods depending on the situation so I want to go over a couple so you don't think opening a new window is the only solution. A new window is best when drilling down several tables deep to create related records of related records. You really have no choice but to open a new window and possibly another new window, depending on how deep you need to go. But, if you have just one level then consider a popover.
Popovers are easy to program and allow access to related data from a portal that is too small to display all the fields. What a popover can't do is allow diving through multiple levels of related records. Just as you can't put a portal inside a portal, you also can't put a Popover inside a Popover.
Other solutions include an email button to access an email address that can't be displayed in the portal. You'll still need a new window or a popover to enter the data (unless there is some other interface outside the current layout) but it can allow you to quickly email a contact, as shown in the example file included with this article.
The same is true for accessing the mobile phone which can't be displayed in the portal. Just use the Dial Phone script step to dial the phone. A major drawback of the Dial Phone script step is it's not compatible with the Macintosh operating system. Windows and iOS are good to go.
Find out More This article comes from an excerpt from my full length videos titled the "Philosophy of FileMaker 20". Just visit:
This blog is completely free. Please support it by clicking on one of the advertisers at the left side of the window or becoming a patron. Thanks so much!
