Sessions in FileMaker Pro

"Sessions" in FileMaker Pro

FileMaker Pro is a client-server application (at least when being used in multi- user states). Each time someone using FileMaker Pro (a client) connects to FileMaker Server and opens an instance of the files hosted there, he creates a session .

In practical terms, this means that one of your users can be on layout #10 while you yourself are working with layout #2. You can run a script and nothing will happen on another user's computer; likewise, someone else can export data on her machine, while you're performing a find request in the very same database table on yours. You each have a separate connection to the database, with its own unique environment. While working with the same data, all your users can be performing separate, distinct tasks in your system. Each user can have a separate view of the database, with different active windows , active tables, or active found sets, among other things.

Generally these individual user sessions don't interfere with each other at all; however, there are cases where they can conflict ”for example, when two users try to edit the same record at once. We will cover throughout this chapter various techniques for identifying and coping with such issues.

NOTE

Keep in mind that sessions pertain only to global fields, window states, and layouts. Actual data is stored and displayed consistently for everyone.

Before approaching how to manage sessions and potential conflicts, it is important to understand what a session is and how FileMaker Pro manages multiple users. In FileMaker Pro, sessions are implicit and enjoy a state-full, persistent, always-on connection to the server. The system preserves and isolates your user experience in the FileMaker Pro client. Keep in mind that after the session is over (the user closes the database), all information about that session ”what layout was in use, where windows were positioned, what the found set was ”is discarded. The next time that user opens the database in question, it opens in its default state, with no preservation of how it was last left the system.

You might have heard the term session as applied to the Web. FileMaker Pro is quite different. On the Web, sessions are stateless. The Web server does not maintain a connection to a user; the behavior of a session is approximated by the explicit creation of an identifier for a given user when she logs in to a system. That identifier is then passed (and often stored/retrieved via a cookie) through all the page requests a person may make in a given time period. Web developers need to overtly create the mechanics of a session to preserve one's experience from page to page. Whenever you buy a book from Amazon, the developers there have no doubt labored to make sure each page you visit tracks sensibly your use of the site ” especially when it comes to the multi-page shopping cart experience.

Session-Specific Elements

FileMaker Pro's sessions maintain a consistent user experience until the application itself is closed. This experience includes your log-in account (unless you specifically log out and log back in), the position and number of windows you have open , which layouts you're on, your current found set, your current sort order, and portal scroll positions . On the development side of things, custom colors you've stored in the layout tools are, unfortunately , lost at the end of a session.

Global Behavior

Globals (fields specified as having global storage) are session-specific and they deserve some additional discussion. In a multi-user client session, they utilize and store values unique to one specific user's session. This enables you as a developer to depend on globals storing different information for each user. A simple example is a displayed account name at the top of each layout set at the time of login.

For more details on global field storage, see "Storage and Indexing," p. 82 .

At the start of a session, each global is initialized to the last value it had in single-user mode. If you run in single-user mode only, this makes the global appear to persist across sessions, but it's misleading to infer that there are multi-user and single-user types of sessions. Using global behaviors as stored across sessions for single users is a handy way to "leave things the way they were," but it also allows developers to create a "default" state for globals.

Globals are used for a range of functions in multi-user databases: They often hold images for navigation and user interface purposes, they hold temporary variables used by scripts, and they sometimes hold session information such as the current date or the active, logged-in user. It makes sense, then, that they'd be specific to a given user's experience.

If your global fields suddenly seem to be holding wrong data, refer to "Unpredictable Global Default Values" in the Troubleshooting section at the end of this chapter.

User Accounts and Session Data

One excellent use of global behavior in a multi-user environment is to set a global field with your currently logged-in account. This enables you to always have a central field that's easy to use in calculation formulas and scripts. One could argue that simply using the Get (AccountName) function wherever necessary would accomplish the same end, but there's a further use for storing the current account name in a global: You can drive a relationship with it into a User table.

This enables you to tie account information to data. You might want to do so if, for example, you need to store someone's real name, his preference to always start on a specific layout when the system opens, or (in a particularly abstract example) in what language he wants to use your database.

All these examples depend on your having done something with the information you store in a user table. It's useful to store someone's preference for starting layout only if you then write the requisite script that uses this as a reference.

Another possibility lies with tracking database use. Although you might debate whether or not a database (or database administrator) should be looking over someone's shoulder, you could write routines that post records to a user log table whenever users log in, log out, or even when they perform certain scripted actions (delete records, create records, run an invoice report, and so on).

One more user-friendly option is to accommodate users simply by enabling them to specify where they prefer a window to be positioned and sized .