Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Global calc fields and relations

1 view
Skip to first unread message

Christoph Kaufmann

unread,
Nov 6, 2009, 5:41:18 PM11/6/09
to
I need a constant value (the number 1 mostly) on the left side of a
relation. I use a calc field with nothing but the figure 1 in it.

Now shall I set this calc field to global storage? I'm not sure what the
pros and cons are, apart from the obvious: that without global storage,
the calc field could be indexed and thus used on the right side of a
relation, and that with global storage, I can put this calc field on
every unrelated table (there's not need for either).

The Finder didn't indicate a change in the file size when I turn global
storage on or off.

One amazing thing, however: The relation with the globally stored calc
field on the left side works with a local file on my FMP 8 A, where both
tables are Filemaker tables.

On a file hosted with FMS 9 and opened with FMP 9, however, the relation
did not work until I turned global storage off. In this case, the calc
field was one of those additional field in an ESS table.

--
http://clk.ch

Remi-Noel Menegaux

unread,
Nov 7, 2009, 2:12:34 AM11/7/09
to
Hi,
Three remarks :
1) a field named 'Constant' and calculated as '1', stays at the value 1
whatever the record. So no need for it being global.
2) 'globals' are 'local' as pertain to the user. This allows different users
to set their own values of their globals, which is handy.
3) we often create a single record table where every field is regular ie non
global. Then each field can be 1) modified by the user (if he is allowed to)
2) used in relationships with other tables. I generally call that table
''parameters", and I use it also for value lists in any table.
HTH.
Remi-Noel

--------------Original Message------------
"Christoph Kaufmann" <c...@tele2.ch> a �crit dans le message de
news:1j8rw37.iht5ft5wbwuyN%c...@tele2.ch...

Christoph Kaufmann

unread,
Nov 7, 2009, 4:47:03 AM11/7/09
to
Remi-Noel Menegaux <rnmen...@free.fr> wrote:

> 1) a field named 'Constant' and calculated as '1', stays at the value 1
> whatever the record. So no need for it being global.

Of course there's no need for the functionality. But are there reasons
for and against setting it to global? File size? Performance?

> 3) we often create a single record table where every field is regular ie non
> global. Then each field can be 1) modified by the user (if he is allowed to)
> 2) used in relationships with other tables. I generally call that table
> ''parameters", and I use it also for value lists in any table.

I assume everybody has been using this technique since the early days of
FMP 3. There's a way to make these fields global, so that you do not
have to add this parameter table to each and every PTO: create a global
field for every data field. The table gets related to itself via the
date field with a calculated constant. The scripts that run when opening
a file call a script that updates the values in the global fields.
--
http://clk.ch

Christoph Kaufmann

unread,
Nov 7, 2009, 12:44:21 PM11/7/09
to
> Remi-Noel Menegaux <rnmen...@free.fr> wrote:

> > 1) a field named 'Constant' and calculated as '1', stays at the value 1
> > whatever the record. So no need for it being global.

Christoph Kaufmann <c...@tele2.ch> wrote:

> Of course there's no need for the functionality. But are there reasons
> for and against setting it to global? File size? Performance?

I have to answer my own question here. There actually is a need to set a
calc field with a constant value for global storage. Without global
storage, we depend on context, and a filtered value list won't work in
an unrelated table.
--
http://clk.ch

MAP

unread,
Nov 7, 2009, 4:32:16 PM11/7/09
to

Thanks Christoph, I was also wondering about global calcs.

Your Name

unread,
Nov 7, 2009, 5:14:34 PM11/7/09
to

"Christoph Kaufmann" <c...@tele2.ch> wrote in message
news:1j8tqkg.ni853qukfeq0N%c...@tele2.ch...

> Christoph Kaufmann <c...@tele2.ch> wrote:
>
> > Of course there's no need for the functionality. But are there reasons
> > for and against setting it to global? File size? Performance?
>
> I have to answer my own question here. There actually is a need to set a
> calc field with a constant value for global storage. Without global
> storage, we depend on context, and a filtered value list won't work in
> an unrelated table.

A Global Number field will usually do.

As for affecting file size, an extra single Number Field isn't going to do a
lot to the file size, unless you've got many hundreds of thousands or many
millions of records.

Helpfull Harry :o)


0 new messages