I took the liberty of popping this into a new thread because its not
really about min/max anymore.

In article <11kqb2ersvb1n8e (AT) corp (DOT) supernews.com>,
howard (AT) antispahm (DOT) fmprosolutions.com says...
Its worth noting that the difference between a global calc and an
unstored regular calc is largely semantic anyway.

I mean, they don't really take up space in the table data, they aren't
indexed or stored. When using them in scripts they both evaluate in
terms of the 'current' record, etc.

The only difference is the *idea* that the global calc only exists once,
while unstored calcs "sort of exist on the fly" for each record. The
upshot of that difference is that when looking at regular unstored calcs
through relationships and it makes sense to see different values for
each record, but not for a global calc -- what *should* a global calc
that references a local field do when viewed in a portal?? How can it
evaluate against the current record *and* be the same (global) for all
records?? Clearly this is pretty clumsy feeling.

I beleive "global calcs" were *intended* to be calculations based on
*globals*; to solve the annoying issue of having a global called
_startdate_parameter and then a local unstored calc _enddate_paramter =
startdate+14. Intuitively you should be able to make that
_enddate_parameter a global as well, because it doesn't make sense to
evaluate it for every record - its a global, its the same for every
record because its based entirely on other globals.

In the original post there is no logical reason that min and max should
be globals at all. It makes sense for these values to exist for each
record, and given that they are calculated on the fly anyway, there is
no loss for doing so - they aren't *global* values anyway. He's sort of
hacked a "constant-dummy-relationship" table with his "peek" construct,
but if it were a more natural relationship in peek, we'd expect min and
max to be local fields in peek as each record in peek would have its own
set of children to min/max.

--

That said - my defense of global calcs has a weakness. You can, after
all, define relationships on globals, and it makes sense to be able to
define global calculations that use those relationships - but I've had a
number of 'display update problems' with 7 & 8 even on regular fields
viewed through global relationships and I think that between the way 7 &
8 do relationships now (bidirectional and deep) and the way globals no
longer lock records - that globals as relationship keys may be a sort of
the 'bastard descendants of filemaker 3/4/5/6 and like repetitions,
should not be used?

Like portals replaced repetitions as the "right way", perhaps using a 1
record (or 1 record per user) Table, for example, is the right way.
(which is now possible in 7/8 as we have more than one table per file.
In many ways this approach actually makes more sense than globals in
relationships.

After all globals don't really fit into relational calculus. They aren't
really table columns - they don't lock the record, they are unique to
each user, and they aren't even persisted to the database when hosted
files are closed. They are much more like variables then fields.

And you can't join a table to a variable... but you can join a table to
a table with a single record table with a single column.

Thoughts?

42 wrote:

We often use relationships to help drive our interface. For example,
you may want to filter a portal, which is based on a relationship, which
is based on user-selected global field as criterion. That's something
to be said for globals.

The one use I like for global calcs is this: I now store some system
preferences in a one-record table -- say, for examle, a logo that I want
to use throughout the system. I could create an 'X' relationship from
every TO to my preferences TO to show the logo that is stored in my
single-record preference table...but that would get kind of ugly. Since
in FM7/8 we can reference global fields in other tables without even
having a relationship, I've created global calcs in my Preferences
table, which DO update themselves whenever I change data in the one
record, and which (by nature of their being global calcs) make
themselves available to other tables without a specific relationship.



--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg (818) 883-2846
FM Pro Solutions Los Angeles, California

FileMaker 7 Certified Developer
Associate Member, FileMaker Solutions Alliance

In article <11kqkcdgktkn38 (AT) corp (DOT) supernews.com>,
howard (AT) antispahm (DOT) fmprosolutions.com says...
Good point. Although, its actually both possible and easy to do
equivalent things with an extra table occurence and relationships, if
you re-think things a bit.

Still I think using globals in relationships in the situation you
describe is possibly more intuitive.

Yeah, that's handy - saves us a relationship - and really further
underscores that globals *aren't* really relational.

These are very thoughtful takes on the issue I presented in my earlier post,
and I'm glad to see it promoted to a new topic of more general significance.

Logically, intuitively, it makes sense (to me at least) for a table to have
a "global" field whenever its value is invariable for all records. Yet,
everything you said about globals and their uncertain role is true.

This is one reason why I took the pains of stepping through the thought
process. Why else offer a Min() function that supports
TableOccurrence::Field as a parameter, when you cannot actually use it that
way easily and/or reliably? Better to prohibit that use altogether than to
have it implemented poorly.

When problems like these crop up, you can just imagine that FileMaker 9 (or
some other future version) will have to eliminate global fields support or
dramatically change the way they work.

I'll admit some amusement at the idea of the Peek table being a "hack," but
I present it mostly as an example or thought experiment. However unnatural
it seems... it's completely "legal." In fact, I submit that some variation
of the very first calculation attempt -- without all the creation of clone
tables and self-joins -- should be sufficient.

[Maybe the answer is a function that forces Min() and functions like it to
consider the found set instead of the current record, much like Extend()
transforms non-repeating fields into repeating ones temporarilly for the
purpose of calculations. Min ( FoundSet ( EntryDate )), anyone?]

At the end of the day, we still don't have a suitable solution for a problem
which should be very straightforward in a FileMaker 7/8 world: Calculating
the minimum value currently stored in a field across a set of records.

Bill


"42" <nospam (AT) nospam (DOT) com> wrote

In article <QPydnXxf-N1u8NDeRVn-1A (AT) comcast (DOT) com>, wjm (AT) wjm (DOT) org says...
Min() is actually highly reliable, and it makes sense for (x::y)
usage...the issues are with globals. Whether it makes sense for global-
calcs to reference non-globals is pretty debatable. Perhaps global calcs
should be restricted to only operating on other globals?? (Although that
will break Howards trick-use.)

My calling it a hack wasn't intended in a disparaging way. It was a
kludge 'work-around' that solved the problem, and I think we all agree
that its not as elegant as it could/should be.

I'd have set it up differently, probably via a self-cross-join... though
I'd have called that a hack in this case as well.

You can do this ("found set" stuff) with summary fields actually. Indeed
if you want "found set" instead of "all records" summary fields are the
way to go.

-regards,
Dave

Howard Schlossberg wrote:

I've done the same thing, use a global calc that gives me the name of
the organization that licensed the solution; a text field in the MAIN
(1 record only) table stores the value and the global calc reads that
value. This works great even in multi-user mode with one exception, in
the following scenario the global will not evaluate properly:
user 1 logs in
Global Registration Code is empty
user 2 log's in and registers
Global Registration Code on User2 computer has updated
user 2 logs out
Global Registration Code on user1 computer has NOT updated
user 1 logs out

The next user that logs in will see the same value for the global that
user 1 last saw; an empty value.