Database Reference
In-Depth Information
POWER USERS' CLINIC: DEVELOPING ON SHARED FILES
Just as many users can work on a shared file, you can do development work in the same file while
users are connected. You—or anyone with the proper privileges—can add or modify tables and
fields, manage relationships, add or edit value lists, add or edit data source references, manage se-
curity, work in Layout mode, and even write scripts. But the one-at-a-time rule again applies: Only
one person can do each task at one time. For example, two people can't edit the same layout at the
same time. If you try to switch to Layout mode when someone else is editing that layout, you'll see
a warning letting you know who's using it and then you have to wait until he's done to make your
changes.
Plus, your work as a developer can conflict with users. For example, you can add new fields or
change their definitions while users go about their daily business. But if someone has a record
locked when you click the Manage Database's Done button, you'll see a warning letting you know
which person hasn't committed their changes. You can send him a custom message, like asking him
to finish editing his current record so you can do your work. But what if several users each have re-
cords locked? You have to ask each one in turn to stop working while you finish up. In a busy work
environment, it can be costly to disrupt several people's workflow just so you can change the calcu-
lation on a field.
The safest practice is never to do development work on a database while users are connected to it.
But since that might limit development work late nights and weekends, many developers end up
working on databases while others are using them. So common sense and a few rules of thumb are
in order. First, remember that the changes you make will affect users as soon as you save them. For
example, if you move a layout object while users are on that layout, they may see objects appear to
jump as soon as you switch to Browse mode. If no one's currently using the database, saving a script
incrementally as you work is a good idea, but if you make a change, save the script and then make
another change, users who run the script will be running it in a semi-edited condition, which could
be disastrous.
If you do have to do development work on a database while people are using it, make sure to let
them know about your planned changes and work schedule ahead of time. Second, if you have more
than about 25 users connected, the risk of corrupting the file is greatly increased. If you absolutely
can't work at night, or if your manufacturing plant runs shifts around the clock, then you may have
to schedule down time for file upgrades. Third, if you're using FileMaker Network Sharing instead
of FileMaker Server, it's just not safe to make changes on shared files. Don't do it.
Setting Up a Host Computer
To set up the host, open the databases you want to share and then choose File→Sharin-
g→Share with FileMaker Clients. This opens the FileMaker Network Settings dialog box
( Figure 19-1 ). After you turn on network sharing for the host computer, you need to tell
FileMaker which databases to share. The FileMaker Network Settings dialog box shows a
Search WWH ::




Custom Search