Hi Jeff
Thank you for your very helpful explanation. You have given me a lot to
think about and work on. I have already encountered the issue of
updating the interface and then having to import data, and that's what
made me think that separating the two would be desirable. You've
obviously perfected the method! It seems that the only time you would
need to update that data file would be if you need to add more
calculation fields to it.
Thanks again
Bruce
Jeff Almquist wrote:
Hi Bruce,
Sounds like you're thinking you need to have local tables in your
interface file ("DisplayNames" was your example) that essentially
mirror the tables (and records) in your data file. This is not the
case. You can create Table Occurrences on the graph in your interface
file that point to the tables in your data file, and you will have
access that data as if it were local. You might also want to use the
technique I use when employing this "separation model", which I'll
describe for you here.
Besides all data tables, I also store FileMaker user accounts and any
user-editable custom value lists in the data file, as well as a basic
spreadsheet (table)-style layout for each table, so certain users
(based on privilege set) can access data directly if necessary.
Calculation fields based on local data such as "full_name" (first_name
& " " & last_name) also reside in the data table. The only scripts in
the data file are some simple ones that are necessary to facilitate
creating, deleting and resetting passwords for FileMaker user
accounts, which the user does from a layout in the interface file.
The interface file contains all other scripts, all other layouts and
two tables: "session" and "global". In the "session" table, a new
record is created upon every login. This is to prevent record-locking
in a multi-user environment, and it can be used to track user login
activity (by creation account, creation date, etc.). There are also
lots of global fields and calculation fields in the session table used
for various interface display. The "global" table in the interface
file stores graphics and various default values, which are used to
populate a corresponding "global" table in the data file with every
time the solution is opened. There's also a field in the interface's
global table that stores and displays the version number, which, of
course, I increment each time I deliver an update.
A typical data-entry layout in the interface file will have one or
more "search" portals, each of which uses a one-to-many relationship
with a global field as its primary key. When the user clicks on a
found record in a portal, a script is executed that sets that record's
key value into another global field, and the necessary fields for that
"selected" record are displayed and/or are editable through a
one-to-one relationship. Basically the user is always "on" the session
record that was created for her when she logged in, and is accessing
data through portals or related fields using dynamically controlled
relationships. I typically don't use List or Table style layouts in
the interface file, except for some reports, where fields are always
non-enterable.
As for being able to swap data files and access them with the same
interface file, I suppose the different data files would either have
to have the exact same name (which would require that they be stored
in different folders and moved around), or you'd have to predefine all
possible data file names as path options in the File Reference
definition. I'd shy away from granting users direct access to File
References.
My purpose for using this separation model, by the way, is to make it
easier for me to update my client's solution. If I'm only making
changes to the interface file, then I can do the development off-site
(using a copy of the data file), and updating the client is as simple
as swapping the interface file for its predecessor - there's no data
importing and no potential for serial-number overlap. For those
reasons the separation model also makes distributing updates for a
commercial solution (multiple customers) really easy.
Jeff
On May 13, 2009, at 1:53 PM, Bruce Button wrote:
Sometimes it is desirable to separate the data from the interface
which manipulates and displays the data - e.g. so that you can use
the same interface with different data.
It seems that the best way to achieve this would be to put the data
in one Filemaker database and the layouts and calculated fields in
another one (i.e. two separate files on disk). To use a trivial
example, say you have the "data" database with a table called Names,
containing fields "Contact ID", "First name", "Surname", and an
"interface" database with a table called DisplayNames that has fields
"Contact ID" (which links to the Names table in the "data" database),
and a calculated field = First name & " " & Surname. Layouts are
stored in the "interface" database.
This seems straightforward, but I am puzzled by some of the issues
that arise in this situation:
1. If you keep your calculated fields in the "interface" database,
and link them to the "data" database using a primary key (as in the
above example), what is the best way of adding records to the
calculated fields table whenever a new record is added to the "data"
database?
2. What happens if you open up a different "data" file in the same
interface? How do you ensure there will be enough records in the
DisplayNames table?
3. Is there any way of defining file references through a script
step? If not, how would you, in an elegant way, allow the user to
select a data file of his/her own choice?
Thanks in anticipation.
Bruce Button
__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4074 (20090514) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
