First, what I have. FMP 5.5 with the files on FMP Server 5.5 and
the each seat is a Windows XP or 2000 computer working with the server
over a fast ethernet connection.
I started experimenting with relationships and lookups because I was
finding many "pieces" of data being repeated over and over (building
names, contacts, phone numbers, etc). For my experiment I had three
data files; Bldg Systems, Contacts, & Building List. The Bldg Systems
file is the master ot target file and filled with mostly related fields
from the Contacts & Building List files (my related or source files).
Each file has a primary key for each record.
I was able to make it all work. I could create a record in the Bldg
Systems file, put in a key for the bldg name, address, etc from the
Building Lists files just fine. Ditto for the Contacts. By simply
changing the key number all the related data (one for the Building info
and one for contacts). Very cool.
Then for fun I changed the name of a building the the Bldg Systems
file and exited the field thinking that it would change back so that it
would match the Building Lists file. Nope, it stayed changed. Not
only that it changed the name of the building in the file called
Building Lists. Yikes! That I don't want at all. There are too many
ditzy people that might use the Bldg Systems file and decided to change
information in it. I don't want that to happen except for a few people
that would understand what they are doing. Is there a way to prevent
those changes to a one way only? That is to say that only those with
access to the Building List can make changes (but will also update or
change the Bldg Systems file)?

In article <060220071511378301%final (AT) xdsysmatrix (DOT) net>, Lee Steffeck
<final (AT) xdsysmatrix (DOT) net> wrote:

I think you're a little confused. Relationships are always only "one
way" - from the main (parent) file to the related (child) file in the
sense of using data. If you want to go the other way to get data from
the parent file into the child file then you have to define a new
Relationship in the child file itself back to the parent file.

What I think you really mean is that you want the relationship to be
"read only". A relationship in FileMaker doesn't have any settings for
"read / write" or "read only" since it simply links the two files /
records together. It's what you do with the related fields that
determines what happens to the related data.

It doesn't sound like Lookups come into this problem at all. Since you
can change the field and that changes the related file's data, you must
be just using the related field directly on the layout. In this case
all you need to do is format the related field(s) on the layout in the
Bldg Systems file to NOT allow user entry. Then the related data will
still display, but the only way to change the Building Name will be in
the Building List file.

- Go into Layout mode

- Click on a field (or multiple fields)

- Choose Field Format from the Format menu

- Turn off the "Allow entry into field" option near the bottom of
the window

- Click on the OK button

- All done!

This can be done for any field, not just related ones. The only problem
is that users cannot use that field to perform Finds with. There are
various ways around this, but it doesn't sound like you need to do that
anyway (although I'm not certain).

Of course, this won't stop anyone simply opening up the Building List
file and changing the data there. To stop that you would need to create
some Access Privileges ... remembering to FIRST create a group /
password that can still access the entire file!!! Otherwise you can
easily lock yourself out of the file entirely.


Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)

In article <070220071816382022%helpful_harry (AT) nom (DOT) de.plume.com>, Helpful
Harry <helpful_harry (AT) nom (DOT) de.plume.com> wrote:

I set the relationship up as a one way, that is the data transfer
from one file to the other. The parent file (if I understand you) is
the Bldg Systems and it taps the child (the Building List) on the
shoulder to say pass me the data please. So when I place a number in
the Bldg Systems ID field it gets the data (from the Building List)
with no problem. Works great. The Bldg Systems file has only two
fields as defined under the File - Define Fields menu. After that I
went into layout mode and used the Insert - Field menu command to add
what I wanted via the already established relationship. Things like
the Bldg Name, Bldg Address, Bldg Number, Bldg City, etc.
But after the data is there, I can change the information in both
files.


I tried lookups first. They also worked. But it also meant that I
would probably have to "force an update" of the lookups to periodically
which I wanted to avoid.


Finds are a definite need. The main reason for the Bldg Systems
file was to obtain certain data from other files without needing to
update by hand two files. If a Contact changes for a building, I
didn't want to have to update the Contact file and the Bldg Systems
file.


That's is the next step I am going to tackle. Or is this the
problem to begin with? Since I have all three databases fully open (no
passwords or access restrictions since I made it for me to tinker with)
that's why the data can be changed from one db to the other? Do I need
to set up a access for the Bldg Systems to NOT allow the data to be
changed, but the user can still "find" or "get" the info? Or would I
be better off putting a password on the Building List db instead?
And based on previous experience, thank goodness you are. You have
saved me some awful headaches and hours of typing. Thank you.

In article <110220070423060304%final (AT) xdsysmatrix (DOT) net>, Lee Steffeck
<final (AT) xdsysmatrix (DOT) net> wrote:

There is no way to set a relationship as "one-way" in the "read only"
sense that you mean, which is where you're getting a little confused. A
relationship simply creates the link between two files (from the file
it is defined in), it's then up to the developer how that link is used
via the normal workings of FileMaker.



Exactly. When you place the related field (eg. Bldg Name) onto a
layout, it *IS* that field and will act just like any normal field,
meaning you can also edit its data.

If you want to make any field (not just related ones) non-editable then
the easiest way is to turn off the "allow user entry" option for that
field, but it only affects the copy of the field displayed that
particular layout.

On your layout in the Bldg Systems file:

- Go into Layout mode

- Click on a field (or multiple fields by holding dow
the Shift key)

- Choose Field Format from the Format menu

- Turn off the "Allow entry into field" option near
the bottom of the window

- Click on the OK button

- All done!

The problem here is that once you do this you can't then use that field
(or fields) on that particular layout to perform Finds - the user can't
type into them. It sounds like you only have one record in the Bldg
Systems file and are just changing the Bldg Systems ID to view the
related data, in which case users won't be performing Finds in the Bldg
Systems file anyway.


Or, another way is ...



Don't use a Lookup, it's useless for what you appear to be trying to
do. You could instead use Calculation fields in the Bldg System file to
copy the data from the related field.
eg.
c_Bldg Name Calculation, Text Result, Unstored
= Relationship::Bldg Name

Being a Calculation field, users can not change the data, but it will
always contain an up-to-date copy of the Bldg Name data from the
Building List file via the current relationship link. Obviously you
would need a Calculation field for each related field you want to
display the data from, so this can get tiresome to set-up.


A third way would be to use Global fields, and then have a "Get Data"
button that runs a script to copy the related data into the Global
fields. Since the Global fields only have a copy of the related data,
changing them will not change the original data. But this would require
extra set-up and buttons to stop confusing users and again you would
need a Global field for each related field.



The Access Privileges can be set in (almost) any way you want, but they
are a little over-complicated to figure out and it's too easy to lock
yourself out of the file by accident. I think you should probably
ignore Access Privileges, especially at this stage.

If you train the users to open the Bldg Systems file, then that's the
only file they will see. The other related files will open
automatically, but remain hidden, although still accessible (the
filenames of hidden files appear in the Window menu in brackets).


Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)

In article <120220071924185573%helpful_harry (AT) nom (DOT) de.plume.com>, Helpful
Harry <helpful_harry (AT) nom (DOT) de.plume.com> wrote:

Yes I noticed that. It was like having one field in two or more
databases. So that I means I will have to use password protection (and
make it the same in each database) otherwise the higher access in one
will override the other.





Well if FM allowed you to enter data in it for the Find Mode only
that would be great, but they don't so that won't be an option.






Actually I had the Bldg Systems file pretty much as the "view only"
file. It will contain over 300 records (since we maintain that many
buildings). That way a user could find the building and see what is in
it. Or do a find for all the buildings on a certain street or for a
certain system.





I had not thought of that, so I will keep that one in mind.





Wouldn't that be good if I only had one record? With several
records that dosen't sound feasible.






I tried it before I read this and it wasn't as hard as I thougt it
would be for users. [Groups would be a different thing I found out
very quickly.] I just had two users: the super user or admin and
another for viewing and printing only (a partial user). When I entered
in the partial user mode everything was the way I wanted it, that is my
"one way" relationship. If I was in super user mode, then things fell
apart and worked the way I described in my first posting.





That will be fine, as long as they don't change the data. It is
there as a view, read, print operation only. Any data changes can be
done be more or one other person that will understand more of what is
happening with the data.