Re: Showing an image, based on the value in a field

In article <1143737478.569143.75810@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
"Carla" <carla_sloan@xxxxxxxxxxx> wrote:

Re. the globals, I was under the impression that in a multi-user setup,
the globals were user-dependent. So thanks for putting me right on
that one - saves a bit of fiddling about in the startup. I'll also
experiment with your suggestion, Remi-Noel - and thanks for the
responses.

Global fields ARE user-dependant when in a multi-user environment, but
not quite in the way you're thinking.

In single-user mode or as the host user of a file, all changes you make
to a Global field are saved with the file. ONLY the changes to Global
fields made by the host are saved. (See Note 1.)

When another user connects to the file they are given COPIES of the
CURRENT Global Field data from the host. After that they become "local"
versions and any changes the user makes are only within their computer.
The user can change the Global field (via scripts, etc. where allowed
by your database design), but the data will only be available on their
computer, not anyone else's. Any changes they make to the "Global"
fields will also NEVER be saved when they quit.

Since the users only receive a copy of the data at the time they
connect, any changes made by the host to Global fields will also not be
seen by any already connected users - they will have to quit and
reconnect to get the new values.

It makes no difference what type of Global data is being used (Text,
Numbers, Container data), so in your case this means you can happily
insert the graphics images into the Global Fields manually when in
Browse mode (as the host or in single-user mode) and they'll be saved
with the file, these will then be copied as the default values when the
file is accessed by another user, so you don't need to have the Opening
Script insert the images every time.


BUT, it also means that you can NOT use Global fields to pass data
values from one user to another or for data that needs to be accessible
/ changeable by everyone.

For example, you set-up a Global field called g_CurrentUsers and have
an Opening Script that adds the current user to this list.
ie.
Set Field [ g_CurrentUsers,
g_CurrentUsers & ", " & Get(CurrentUserName)]

Now, when the first person / host opens the file the field is given
their User Name, eg. "Fred Flintstone".

When the second person connects to the database they are given a copy
of the field that says "Fred Flintstone" and the Opening Script adds
their User Name (eg. "Fred Flintstone, Barney Rubble"), but those two
names are only available to that user - the host still only sees "Fred
Flintstone".

If a third person comes along then they get a copy of the host's Global
field and their name is added, giving them "Fred Flintstone, Wilma
Flintstone" - they don't see the second user in this field's data, and
the host still only sees "Fred Flintstone".

Plus, when the connected users quit their Global field values are lost,
so the field will be saved as just "Fred Flintstone" when the host user
quits (unless you have a Closing Script that empties the field of
course).

If you need to have changing data values accessible by ALL users in a
true "global" sense, then they have to be stored in a separate file /
table as NORMAL records. Usually developers have a "Preferences" (or
similar) file / table that has one record using normal fields to store
all the fully accessible data ... it also gets more complicated since
you have to add some 'error checking' to make sure the record isn't
already being used by someone else before trying to change the values.


Notes:
1. When using FileMaker Server (or whatever it's called today), the
Server is the host and so EVERYONE connecting is a simple a user, which
means nobody can save changes to Global field data.

2. When using "Save As A Copy" within FileMaker and choosing the Clone
option, ALL Global field values are lost as well as normal field
values. This can be painfully annoying since you then have to go
through and re-enter all the default values. :o\ It's better to save
a normal or compressed copy, then delete all the records from the copy
instead, that way the Global values are kept intact.



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

Relevant Pages

  • Re: Question about FIIND LAYOUT
    ... In Find mode you can't click into a global field, ... same value so entering data in it is useless. ... You can still use globals to transfer data in Find mode. ...
    (comp.databases.filemaker)
  • Re: creating related record
    ... Indeed I am stuck to old habbits of using globals instead, ... > you know to look for your global field up in the A's or down in the Z's? ... > FM Pro Solutions Los Angeles, ... > Associate Member, FileMaker Solutions Alliance ...
    (comp.databases.filemaker)
  • Re: Stored results vs custom function
    ... Globals can't ... But local variables can be used for this. ... a regular or global field already -- so its not really a good reason ... For that matter, why can't we use field names in paths? ...
    (comp.databases.filemaker)
  • Re: OT: Q: Anyone know PHP well?
    ... Well in the meantime if the problem is register globals and your host allows it you could try doing the following. ... create a .htaccess file in the root of the php code ...
    (rec.games.pinball)
  • Re: OT: Q: Anyone know PHP well?
    ... I appreciate your input, Patrick. ... I guess the profs who pounded the *do not use globals* into my head got through to me successfully. ... I was having *a lot* of difficulty uploading my old website's backup file to the new host. ... I moved the newly created .htaccess file from /home into my public_html directory, and the PHP code was still not executing. ...
    (rec.games.pinball)