Instant Web Publishing Guide

30 FileMaker Instant Web Publishing Guide
1 If your layout contains a portal, related records also display in a web browser within a portal, provided
that the related file or table is also shared with Instant Web Publishing. When you submit a record
containing a portal you might be notified that another user has modified one of the records since you
loaded the page. If this occurs, refresh your page and submit the data again. If this is a likely scenario,
consider using portals as “read only” forms. Alternatively, you can edit related record data in portals by
using the Go To Related Record script step and editing them directly.
1 Web users can create and edit portal records, including filtered portal records. To delete a portal record,
you must provide a scripted button that selects the appropriate portal record, then deletes it. Web users
cannot create or change portal filters.
1 When a published database file contains references to a protected related file that it is not authorized to
access, web users cannot authorize access to the protected file in Instant Web Publishing. Consequently,
when web users open the published database file, the file does not contain any data from the protected
file. To prevent this, be sure to use FileMaker Pro to authorize all files that reference protected files. For
more information on authorizing access to protected files in a multi-file solution, see FileMaker Pro Help.
General database design considerations
Keep the following points in mind:
1 If you are designing a database that will be accessed by both Instant Web Publishing and FileMaker Pro
network clients, it’s best to design with web clients in mind to ensure compatibility across both technologies.
1 Communication from a client to the FileMaker host goes through intermediary technologies with Instant
Web Publishing. When you request data with Instant Web Publishing, you are sending the request from
a web browser to a virtual FileMaker environment, which processes your request, then requests and
retrieves the results from FileMaker
Pro. These results are then passed back to the browser. This
interaction is usually undetectable to web users, but occasionally you must take action to make sure the
results are the same regardless of how clients access your database. Because web users don’t have a direct
connection to the host, they aren’t notified immediately when data changes. For example, you may need
to update your scripts to include the Commit Records/Requests script step to refresh the browser window.
For more information, see
“Script steps tips and considerations” on page 34 and “Creating a script to log
out of a database and close the session” on page 37.
1 Each database must be assigned a unique filename, when you host them with Instant Web Publishing. If
you have two hosted databases with the same name, only one appears in the Database Homepage in
Instant Web Publishing.
1 When defining account names and passwords, avoid characters that may be interpreted incorrectly on the
web. You may want to limit account names and passwords to alphabetic and numeric characters only.
1 It is best not to set too many field validations on a layout. In FileMaker Pro, validation is checked when
users click out of a field. In Instant Web Publishing, validation is only checked when users click the
Submit button, at which time, a message for the first validation error will be returned. After users correct
the first validation error, a message for the next validation error will be returned, and so on. Web users
must correct all validation errors sequentially before being allowed to submit a record.
1 Typically, third party plug-ins can be used for web published databases if they do not attempt to display
information to an end-user’s screen, if they do not require direct end-user interaction, if they do not
interact with the FileMaker Pro user interface, or otherwise require interaction from end users.