Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.databases.filemaker > #1495 > unrolled thread

Value Not Dependent on the Found Set

Back to article view | Back to comp.databases.filemaker

Contents

  Value Not Dependent on the Found Set csampson@inetworld.net (Charles H. Sampson) - 2013-11-11 09:16 -0800
    Re: Value Not Dependent on the Found Set Howard - FM Pro Solutions <fmprosolutions@gmail.com> - 2013-11-11 09:33 -0800
      Re: Value Not Dependent on the Found Set csampson@inetworld.net (Charles H. Sampson) - 2013-11-13 09:47 -0800
        Re: Value Not Dependent on the Found Set Erik Appeldoorn <ursus.kirk@gmail.com> - 2013-11-13 19:29 +0100
          Re: Value Not Dependent on the Found Set csampson@inetworld.net (Charles H. Sampson) - 2013-11-16 00:01 -0800
            Re: Value Not Dependent on the Found Set "E. Appeldoorn" <ursus.kirk@ziggo.nl> - 2013-11-16 10:24 +0100
              Re: Value Not Dependent on the Found Set csampson@inetworld.net (Charles H. Sampson) - 2013-11-18 10:14 -0800
                Re: Value Not Dependent on the Found Set Helpful Harry <HelpfulHarry@BusyWorking.com> - 2013-11-19 08:42 +1300
                  Re: Value Not Dependent on the Found Set csampson@inetworld.net (Charles H. Sampson) - 2013-11-19 09:20 -0800
                    Re: Value Not Dependent on the Found Set Helpful Harry <HelpfulHarry@BusyWorking.com> - 2013-11-20 09:08 +1300
        Re: Value Not Dependent on the Found Set Helpful Harry <HelpfulHarry@BusyWorking.com> - 2013-11-14 09:19 +1300
          Re: Value Not Dependent on the Found Set csampson@inetworld.net (Charles H. Sampson) - 2013-11-16 00:01 -0800
        Re: Value Not Dependent on the Found Set Howard - FM Pro Solutions <fmprosolutions@gmail.com> - 2013-11-13 12:41 -0800
          Re: Value Not Dependent on the Found Set Helpful Harry <HelpfulHarry@BusyWorking.com> - 2013-11-14 18:57 +1300
          Re: Value Not Dependent on the Found Set csampson@inetworld.net (Charles H. Sampson) - 2013-11-16 00:01 -0800
            Re: Value Not Dependent on the Found Set Howard Schlossberg <howard@nospam.fmprosolutions.com> - 2013-11-16 15:08 -0800
              Re: Value Not Dependent on the Found Set Helpful Harry <HelpfulHarry@BusyWorking.com> - 2013-11-17 12:43 +1300
                Re: Value Not Dependent on the Found Set csampson@inetworld.net (Charles H. Sampson) - 2013-11-18 06:58 -0800
              Re: Value Not Dependent on the Found Set csampson@inetworld.net (Charles H. Sampson) - 2013-11-18 10:02 -0800
                Re: Value Not Dependent on the Found Set csampson@inetworld.net (Charles H. Sampson) - 2013-11-20 07:00 -0800
                  Re: Value Not Dependent on the Found Set Howard - FM Pro Solutions <fmprosolutions@gmail.com> - 2013-11-20 09:44 -0800
                    Re: Value Not Dependent on the Found Set Helpful Harry <HelpfulHarry@BusyWorking.com> - 2013-11-21 09:04 +1300
                      Re: Value Not Dependent on the Found Set Howard - FM Pro Solutions <fmprosolutions@gmail.com> - 2013-11-20 12:55 -0800
                      Re: Value Not Dependent on the Found Set clkaufmann@gmx.ch (Christoph Kaufmann) - 2013-11-21 16:59 +0100
                        Re: Value Not Dependent on the Found Set Helpful Harry <HelpfulHarry@BusyWorking.com> - 2013-11-22 09:22 +1300
    Re: Value Not Dependent on the Found Set clkaufmann@gmx.ch (Christoph Kaufmann) - 2013-11-11 19:38 +0100
    Re: Value Not Dependent on the Found Set csampson@inetworld.net (Charles H. Sampson) - 2013-11-20 23:00 -0800

Page 1 of 2  [1] 2  Next page →

#1495 — Value Not Dependent on the Found Set

     I'm still struggling with Filemaker's concept of a field whose
value is defined by a formula when that value's being incorrect is
apparently acceptable. I have a new but perhaps related question: Is it
possible to create an expression (specifically, the value of a field)
that depends on the entire database, not just the current found set?

     I working with Filemaker Pro 8.

                        Charlie
-- 
Nobody in this country got rich on his own.  You built a factory--good.
But you moved your goods on roads we all paid for.  You hired workers we
all paid to educate. So keep a big hunk of the money from your factory.
But take a hunk and pay it forward.  Elizabeth Warren (paraphrased)

[toc] | [next] | [standalone]

#1496

If you have an UNSTORED (calc field) value, then it will automatically update itself whenever one of its dependencies are changed.  If you want a STORED dependent field to change, then you'll need to somehow force-trigger that change through a script or sometimes through use of the Evaluate() function with dependencies specified.

Most calc functions are dependent NOT on the found set but rather on either the current record or else sets of data specified through relationships.  Please provide an example of what you are trying to do so that we can more specifically help you.

Howard


On Monday, November 11, 2013 9:16:42 AM UTC-8, Charles H. Sampson wrote:
> I'm still struggling with Filemaker's concept of a field whose
> 
> value is defined by a formula when that value's being incorrect is
> 
> apparently acceptable. I have a new but perhaps related question: Is it
> 
> possible to create an expression (specifically, the value of a field)
> 
> that depends on the entire database, not just the current found set?
> 
> 
> 
>      I working with Filemaker Pro 8.

[toc] | [prev] | [next] | [standalone]

#1500

Howard - FM Pro Solutions <fmprosolutions@gmail.com> wrote:

> If you have an UNSTORED (calc field) value, then it will automatically
> update itself whenever one of its dependencies are changed.  If you want a
> STORED dependent field to change, then you'll need to somehow
> force-trigger that change through a script or sometimes through use of the
> Evaluate() function with dependencies specified.

     I am now aware of this. Even though it was not to the point of my
original post, I feel compelled to comment.

     The true believers in FileMaker seem to accept this the way of the
world. Here's what I, as a long-time designer and implementer of systems
software, see. With FileMaker we have a piece of software that permits
users to say, "Here is a formula. I want the value of that formula to be
put in this location." The implementers of FileMaker then say, "Fine.
We'll do that for you sometimes and sometimes we'll put a value that has
nothing to do with your formula." The only word that describes such an
"implementation" is "absurd".

     The database program that I'm currently using  -- and hope to
replace with FileMaker -- is from the 1980s. It has no such problem.
Update something that a formula depends on and the value of the formula
is changed automatically, without exception

> Most calc functions are dependent NOT on the found set but rather on
> either the current record or else sets of data specified through
> relationships.  Please provide an example of what you are trying to do so
> that we can more specifically help you.

     O. k. The database in question implements a checkbook. (I know
about Quicken.) One of the fields in this database is used to indicate
whether an item has cleared or not. This field is not on most layouts
but it is on the layout for balancing the checkbook. That layout has a
footer field that presents the checking account balance as the bank sees
it -- without considering any unprocessed items. When going into
checkbook-balancing mode (using a script) this layout is presented and a
Find results in only the unreconciled items being displayed. The value
in the field for displaying the balance as the bank sees it is
calculated incorrectly.

     After spending a silly amout of time trying to figure out what I
had done wrong, I said, "Let's see what happens if I use all the records
of the database with this layout." Bingo. Everything works as it does
with my 1980s database program.

     On this point, I'm not complaining about FileMaker. I'm just
wondering if there's some way of telling FileMaker to use all records in
evaluating a formula without regard to any found set.

> On Monday, November 11, 2013 9:16:42 AM UTC-8, Charles H. Sampson wrote:
> > I'm still struggling with Filemaker's concept of a field whose
> > value is defined by a formula when that value's being incorrect is
> > apparently acceptable. I have a new but perhaps related question: Is it
> > possible to create an expression (specifically, the value of a field)
> > that depends on the entire database, not just the current found set?
> > 
> >      I'm working with Filemaker Pro 8.

                        Charlie
-- 
Nobody in this country got rich on his own.  You built a factory--good.
But you moved your goods on roads we all paid for.  You hired workers we
all paid to educate. So keep a big hunk of the money from your factory.
But take a hunk and pay it forward.  Elizabeth Warren (paraphrased)

[toc] | [prev] | [next] | [standalone]

#1501

Charles H. Sampson schreef op 13-11-2013 18:47:

you could use a cartesian join between two tables. Donoted by an X in 
the graph. I suppose you know about cartesian joins.... (did they exist 
with FMP 8?)

keep well, Erik

>
>       After spending a silly amout of time trying to figure out what I
> had done wrong, I said, "Let's see what happens if I use all the records
> of the database with this layout." Bingo. Everything works as it does
> with my 1980s database program.
>
>       On this point, I'm not complaining about FileMaker. I'm just
> wondering if there's some way of telling FileMaker to use all records in
> evaluating a formula without regard to any found set.
>
>> On Monday, November 11, 2013 9:16:42 AM UTC-8, Charles H. Sampson wrote:
>>> I'm still struggling with Filemaker's concept of a field whose
>>> value is defined by a formula when that value's being incorrect is
>>> apparently acceptable. I have a new but perhaps related question: Is it
>>> possible to create an expression (specifically, the value of a field)
>>> that depends on the entire database, not just the current found set?
>>>
>>>       I'm working with Filemaker Pro 8.
>
>                          Charlie
>


-- 
met vriendelijke groeten,
Erik Appeldoorn

[toc] | [prev] | [next] | [standalone]

#1508

Erik Appeldoorn <ursus.kirk@gmail.com> wrote:

> Charles H. Sampson schreef op 13-11-2013 18:47:
> 
> you could use a cartesian join between two tables. Donoted by an X in
> the graph. I suppose you know about cartesian joins.... (did they exist
> with FMP 8?)

     I have only one table, which represents my checking account. Are
you suggesting that I should define some second table and use it as part
of a cartesian join just to get a formula evaluated properly?

> >
> >       After spending a silly amout of time trying to figure out what I
> > had done wrong, I said, "Let's see what happens if I use all the records
> > of the database with this layout." Bingo. Everything works as it does
> > with my 1980s database program.
> >
> >       On this point, I'm not complaining about FileMaker. I'm just
> > wondering if there's some way of telling FileMaker to use all records in
> > evaluating a formula without regard to any found set.
> >
> >> On Monday, November 11, 2013 9:16:42 AM UTC-8, Charles H. Sampson wrote:
> >>> I'm still struggling with Filemaker's concept of a field whose
> >>> value is defined by a formula when that value's being incorrect is
> >>> apparently acceptable. I have a new but perhaps related question: Is it
> >>> possible to create an expression (specifically, the value of a field)
> >>> that depends on the entire database, not just the current found set?
> >>>
> >>>       I'm working with Filemaker Pro 8.

                        Charlie
-- 
Nobody in this country got rich on his own.  You built a factory--good.
But you moved your goods on roads we all paid for.  You hired workers we
all paid to educate. So keep a big hunk of the money from your factory.
But take a hunk and pay it forward.  Elizabeth Warren (paraphrased)

[toc] | [prev] | [next] | [standalone]

#1513

Charles H. Sampson schreef op 16-11-2013 09:01:
> Erik Appeldoorn <ursus.kirk@gmail.com> wrote:
>
>> Charles H. Sampson schreef op 13-11-2013 18:47:
>>
>> you could use a cartesian join between two tables. Donoted by an X in
>> the graph. I suppose you know about cartesian joins.... (did they exist
>> with FMP 8?)
>
>       I have only one table, which represents my checking account. Are
> you suggesting that I should define some second table and use it as part
> of a cartesian join just to get a formula evaluated properly?
>

Actualy not a second table, but a new TableOccurrance of the first table.

A single table in itself isn't al that usefull, unless you are building 
a very simple solutions. But you can define to reuse a table in any way 
shape or form you want (Well almost.....). A common solution has 
multiple tables connected in several ways, looking like a squid, 
therefor named a squid-graph. But nothing prevents you from reusing a 
table and joining it to its orriginal occurrance. But all depends on 
your needs.

Also may I humbly suggest to stop comparing Filemaker to anything you 
have previously learned. If I was to learn something new after all those 
years of using filemaker I would also struggle. But resisting by 
shouting that the new program makes no sense would get me nowhere.

Filemaker is NOT excel, which is NOT photoshop, which is Not SQL, 
(although SQL now can be used), which is NOT a banana.

-- 
met vriendelijke groeten,
Erik Appeldoorn

[toc] | [prev] | [next] | [standalone]

#1518

E. Appeldoorn <ursus.kirk@ziggo.nl> wrote:

> Also may I humbly suggest to stop comparing Filemaker to anything you
> have previously learned. If I was to learn something new after all those
> years of using filemaker I would also struggle. But resisting by 
> shouting that the new program makes no sense would get me nowhere.

     Point taken and I think I've given a wrong impression by bringing
up my current database program. I only mentioned it to point out that,
as old and clunky as it is (it ran on a Mac Plus after all), it did what
the user told it to do and did not mix up orthogonal concepts. However,
it is indeed old and clunky and I have to replace it with something. I
was hoping that something would be FileMaker. My complaints aside, it
might still be.

     I approached FileMaker with some trepidation, fearing that what I
had learned about databases largely from that old, idiosyncratic,
program would make learning FileMaker difficult. I was pleased to find
out that I wasn't too far off FileMaker's path. FileMaker has a lot of
what I am looking for as I perform this long-overdue upgrade.

                        Charlie
-- 
Nobody in this country got rich on his own.  You built a factory--good.
But you moved your goods on roads we all paid for.  You hired workers we
all paid to educate. So keep a big hunk of the money from your factory.
But take a hunk and pay it forward.  Elizabeth Warren (paraphrased)

[toc] | [prev] | [next] | [standalone]

#1519

In article <1lcizy0.vpv54s159q3kfN%csampson@inetworld.net>, Charles H.
Sampson <csampson@inetworld.net> wrote:

> E. Appeldoorn <ursus.kirk@ziggo.nl> wrote:
> 
> > Also may I humbly suggest to stop comparing Filemaker to anything you
> > have previously learned. If I was to learn something new after all those
> > years of using filemaker I would also struggle. But resisting by 
> > shouting that the new program makes no sense would get me nowhere.
> 
>      Point taken and I think I've given a wrong impression by bringing
> up my current database program. I only mentioned it to point out that,
> as old and clunky as it is (it ran on a Mac Plus after all), it did what
> the user told it to do 
<snip>

FileMaker does what you tell it to ... the problem is you don't know
what you're doing and would rather complain about FileMaker than learn
to use it. When people try to give you the answer you say it's silly.

Helpful Harry  :o)

[toc] | [prev] | [next] | [standalone]

#1523

Helpful Harry <HelpfulHarry@BusyWorking.com> wrote:

> In article <1lcizy0.vpv54s159q3kfN%csampson@inetworld.net>, Charles H.
> Sampson <csampson@inetworld.net> wrote:
> 
> > E. Appeldoorn <ursus.kirk@ziggo.nl> wrote:
> > 
> > > Also may I humbly suggest to stop comparing Filemaker to anything you
> > > have previously learned. If I was to learn something new after all those
> > > years of using filemaker I would also struggle. But resisting by 
> > > shouting that the new program makes no sense would get me nowhere.
> > 
> >      Point taken and I think I've given a wrong impression by bringing
> > up my current database program. I only mentioned it to point out that,
> > as old and clunky as it is (it ran on a Mac Plus after all), it did what
> > the user told it to do 
> <snip>
> 
> FileMaker does what you tell it to ... the problem is you don't know
> what you're doing and would rather complain about FileMaker than learn
> to use it. When people try to give you the answer you say it's silly.

    O man with the most inappropriate ID ever, let's try this again. I
tell FileMaker, "I want this field's value to be given by this formula."
FileMaker says, "I might do that or I might not." I don't see how that
can be interpreted as "FileMaker does what you tell it to."

                        Charlie
-- 
Nobody in this country got rich on his own.  You built a factory--good.
But you moved your goods on roads we all paid for.  You hired workers we
all paid to educate. So keep a big hunk of the money from your factory.
But take a hunk and pay it forward.  Elizabeth Warren (paraphrased)

[toc] | [prev] | [next] | [standalone]

#1525

In article <1lcksfq.1xacu5019ktti0N%csampson@inetworld.net>, Charles H.
Sampson <csampson@inetworld.net> wrote:
> Helpful Harry <HelpfulHarry@BusyWorking.com> wrote:
> > In article <1lcizy0.vpv54s159q3kfN%csampson@inetworld.net>, Charles H.
> > Sampson <csampson@inetworld.net> wrote:
> > > E. Appeldoorn <ursus.kirk@ziggo.nl> wrote:
> > > 
> > > > Also may I humbly suggest to stop comparing Filemaker to anything you
> > > > have previously learned. If I was to learn something new after all those
> > > > years of using filemaker I would also struggle. But resisting by 
> > > > shouting that the new program makes no sense would get me nowhere.
> > > 
> > >      Point taken and I think I've given a wrong impression by bringing
> > > up my current database program. I only mentioned it to point out that,
> > > as old and clunky as it is (it ran on a Mac Plus after all), it did what
> > > the user told it to do 
> > <snip>
> > 
> > FileMaker does what you tell it to ... the problem is you don't know
> > what you're doing and would rather complain about FileMaker than learn
> > to use it. When people try to give you the answer you say it's silly.
> 
>     O man with the most inappropriate ID ever, let's try this again. I
> tell FileMaker, "I want this field's value to be given by this formula."
> FileMaker says, "I might do that or I might not." I don't see how that
> can be interpreted as "FileMaker does what you tell it to."

Because you weren't telling FileMaker to do it correctly. 

FileMaker does not and cannot just do things randomly by itself - it
only ever does what you tell it to, and since you didn't know what you
were doing, you obviously got the formula wrong and/or set it up
incorrectly ... and whining on about FileMaker being silly, even when
you've been given the correct way, just proves you're an idiot who
isn't really interested in learning or being helped.

Next time ask a sensible question, without whining, and perhaps with
more detail of what you're trying to do.

Helpful Harry  :o)

[toc] | [prev] | [next] | [standalone]

#1502

In article <1lc9olh.fh6kuzk00mfN%csampson@inetworld.net>, Charles H.
Sampson <csampson@inetworld.net> wrote:

> Howard - FM Pro Solutions <fmprosolutions@gmail.com> wrote:
> 
> > If you have an UNSTORED (calc field) value, then it will automatically
> > update itself whenever one of its dependencies are changed.  If you want a
> > STORED dependent field to change, then you'll need to somehow
> > force-trigger that change through a script or sometimes through use of the
> > Evaluate() function with dependencies specified.
> 
>      I am now aware of this. Even though it was not to the point of my
> original post, I feel compelled to comment.
> 
>      The true believers in FileMaker seem to accept this the way of the
> world. Here's what I, as a long-time designer and implementer of systems
> software, see. With FileMaker we have a piece of software that permits
> users to say, "Here is a formula. I want the value of that formula to be
> put in this location." The implementers of FileMaker then say, "Fine.
> We'll do that for you sometimes and sometimes we'll put a value that has
> nothing to do with your formula." The only word that describes such an
> "implementation" is "absurd".
> 
>      The database program that I'm currently using  -- and hope to
> replace with FileMaker -- is from the 1980s. It has no such problem.
> Update something that a formula depends on and the value of the formula
> is changed automatically, without exception

FileMaker doesn't put random values into the field. The value will
definitely be based on the formula ... but your formula does of course
have to be correct and Unstored (if you want it to update
automatically). If you're getting strange values, then it's usually due
to the formula being incorrect in some way.

Other applications do also have this option, of not automatically
updating calculations - Excel being the most widely used.

Personally, I've never seen a use for stored calculation values either.
It seems pretty pointless since you may as well use either a normal
field (perhaps with an auto-enter by calculation option), and then
change the values there as needed via a Script, etc. ... but then again
I haven't yet used a version of FileMaker with this ability.




> > Most calc functions are dependent NOT on the found set but rather on
> > either the current record or else sets of data specified through
> > relationships.  Please provide an example of what you are trying to do so
> > that we can more specifically help you.
> 
>      O. k. The database in question implements a checkbook. (I know
> about Quicken.) One of the fields in this database is used to indicate
> whether an item has cleared or not. This field is not on most layouts
> but it is on the layout for balancing the checkbook. That layout has a
> footer field that presents the checking account balance as the bank sees
> it -- without considering any unprocessed items. When going into
> checkbook-balancing mode (using a script) this layout is presented and a
> Find results in only the unreconciled items being displayed. The value
> in the field for displaying the balance as the bank sees it is
> calculated incorrectly.
> 
>      After spending a silly amout of time trying to figure out what I
> had done wrong, I said, "Let's see what happens if I use all the records
> of the database with this layout." Bingo. Everything works as it does
> with my 1980s database program.
> 
>      On this point, I'm not complaining about FileMaker. I'm just
> wondering if there's some way of telling FileMaker to use all records in
> evaluating a formula without regard to any found set.

That depends on what you're using to calculate the "total".

Calculations work out their values based on the current record. 

If the calcuation uses a field via a Relationship link, then some
functions (e.g. Sum, Max, etc.) will work out the value across all the
records related to the current record.

Some functions will only retrieve the first related record's value
(where "first" depens on the Relationship's sort order). For example a
Calculation that says Relationship::RelatedField + 2 will only use the
RelatedField value of the first related record.

Summary fields work out their values based on the Found Set, or a
sub-sorted section of it, and it depends where on the Layout you put
them as to what value they will calculate.

As with all programming, it's a matter of working out what you're
wanting to do, and then using the appropriate method to do that -
there's no pievce of software yet that can read your mind to know what
you really want to do and do it for you.


Helpful Harry  :o)

[toc] | [prev] | [next] | [standalone]

#1509

Helpful Harry <HelpfulHarry@BusyWorking.com> wrote:

> In article <1lc9olh.fh6kuzk00mfN%csampson@inetworld.net>, Charles H.
> Sampson <csampson@inetworld.net> wrote:
> 
> > Howard - FM Pro Solutions <fmprosolutions@gmail.com> wrote:
> > 
> > > If you have an UNSTORED (calc field) value, then it will automatically
> > > update itself whenever one of its dependencies are changed.  If you want a
> > > STORED dependent field to change, then you'll need to somehow
> > > force-trigger that change through a script or sometimes through use of the
> > > Evaluate() function with dependencies specified.
> > 
> >      I am now aware of this. Even though it was not to the point of my
> > original post, I feel compelled to comment.
> > 
> >      The true believers in FileMaker seem to accept this the way of the
> > world. Here's what I, as a long-time designer and implementer of systems
> > software, see. With FileMaker we have a piece of software that permits
> > users to say, "Here is a formula. I want the value of that formula to be
> > put in this location." The implementers of FileMaker then say, "Fine.
> > We'll do that for you sometimes and sometimes we'll put a value that has
> > nothing to do with your formula." The only word that describes such an
> > "implementation" is "absurd".
> > 
> >      The database program that I'm currently using  -- and hope to
> > replace with FileMaker -- is from the 1980s. It has no such problem.
> > Update something that a formula depends on and the value of the formula
> > is changed automatically, without exception
> 
> FileMaker doesn't put random values into the field. The value will
> definitely be based on the formula ... but your formula does of course
> have to be correct and Unstored (if you want it to update
> automatically). If you're getting strange values, then it's usually due
> to the formula being incorrect in some way.

     The formula is correct. It says to take the current balance as the
checkbook sees it and make the appropriate adjustments for uncleared
items to get the balance as the bank sees it. The formula works as soon
as I use all records of the data base. My original question was, is it
possible to tell a formula to use all records of the database rather
than just those of the current found set.

> Other applications do also have this option, of not automatically
> updating calculations - Excel being the most widely used.
> 
> Personally, I've never seen a use for stored calculation values either.
> It seems pretty pointless since you may as well use either a normal
> field (perhaps with an auto-enter by calculation option), and then
> change the values there as needed via a Script, etc. ... but then again
> I haven't yet used a version of FileMaker with this ability.
> 
> > > Most calc functions are dependent NOT on the found set but rather on
> > > either the current record or else sets of data specified through
> > > relationships.  Please provide an example of what you are trying to do so
> > > that we can more specifically help you.
> > 
> >      O. k. The database in question implements a checkbook. (I know
> > about Quicken.) One of the fields in this database is used to indicate
> > whether an item has cleared or not. This field is not on most layouts
> > but it is on the layout for balancing the checkbook. That layout has a
> > footer field that presents the checking account balance as the bank sees
> > it -- without considering any unprocessed items. When going into
> > checkbook-balancing mode (using a script) this layout is presented and a
> > Find results in only the unreconciled items being displayed. The value
> > in the field for displaying the balance as the bank sees it is
> > calculated incorrectly.
> > 
> >      After spending a silly amout of time trying to figure out what I
> > had done wrong, I said, "Let's see what happens if I use all the records
> > of the database with this layout." Bingo. Everything works as it does
> > with my 1980s database program.
> > 
> >      On this point, I'm not complaining about FileMaker. I'm just
> > wondering if there's some way of telling FileMaker to use all records in
> > evaluating a formula without regard to any found set.
> 
> That depends on what you're using to calculate the "total".

     ?

> Calculations work out their values based on the current record. 

     ?

> If the calcuation uses a field via a Relationship link, then some
> functions (e.g. Sum, Max, etc.) will work out the value across all the
> records related to the current record.

     This is a simple database consisting of one table. There are no
relationship links.

> Some functions will only retrieve the first related record's value
> (where "first" depens on the Relationship's sort order). For example a
> Calculation that says Relationship::RelatedField + 2 will only use the
> RelatedField value of the first related record.

     Presumably you're talking about a one-to-many relationship. That's
not applicable to the extant case.

> Summary fields work out their values based on the Found Set, or a
> sub-sorted section of it, and it depends where on the Layout you put
> them as to what value they will calculate.

     No summary fields are involved in the case I'm talking about.

> As with all programming, it's a matter of working out what you're
> wanting to do, and then using the appropriate method to do that -
> there's no pievce of software yet that can read your mind to know what
> you really want to do and do it for you.

     You apparently have no idea of how supercilious that is.

                        Charlie
-- 
Nobody in this country got rich on his own.  You built a factory--good.
But you moved your goods on roads we all paid for.  You hired workers we
all paid to educate. So keep a big hunk of the money from your factory.
But take a hunk and pay it forward.  Elizabeth Warren (paraphrased)

[toc] | [prev] | [next] | [standalone]

#1503

On Wednesday, November 13, 2013 9:47:36 AM UTC-8, Charles H. Sampson wrote:
> Howard - FM Pro Solutions <fmprosolutions@gmail.com> wrote:
> 
> > If you have an UNSTORED (calc field) value, then it will automatically
> 
> > update itself whenever one of its dependencies are changed.  If you want a
> 
> > STORED dependent field to change, then you'll need to somehow
> 
> > force-trigger that change through a script or sometimes through use of the
> 
> > Evaluate() function with dependencies specified.
> 

>      The true believers in FileMaker seem to accept this the way of the
> 
> world. Here's what I, as a long-time designer and implementer of systems
> 
> software, see. With FileMaker we have a piece of software that permits
> 
> users to say, "Here is a formula. I want the value of that formula to be
> 
> put in this location." The implementers of FileMaker then say, "Fine.
> 
> We'll do that for you sometimes and sometimes we'll put a value that has
> 
> nothing to do with your formula." The only word that describes such an
> 
> "implementation" is "absurd".


Those of us who understand how FIleMaker works are fine with doing it the "FileMaker way".  I'm not sure that's absurd; it's just reality.

But let's look at other databases.  SQL, in all its various flavors, is the most widely used database language, and as far as I know, none of the most popular flavors of SQL (MySql, MS-SQL, Oracle) have fields that fill in automatically with sums from other tables -- at least not without a defined trigger, which I think is all I was suggesting in showing how you can use FileMaker to do the same.  SQL has "views", in which you can define such auto-calcs, but then why not just define the total within whatever UI you are using with that SQL.

And so back to FileMaker, you can use an unstored calc (defined as a field, but set to be unstored) to do what you want.  I'm not sure why that's absurd.  But why even bother with a calc field when you are using a script anyhow to arrive at the layout you want to use? Why not add a small routine in that script to go to all records in a new, hidden window, grab the total, plug it into a global field or variable, and then display it on your UI layout?  (In more current versions of FileMaker, you could also just make a quick SQL call within your script or unstored calc to grab the total for all records despite the current found set.)

Sorry if this doesn't help your understanding of FileMaker.

[toc] | [prev] | [next] | [standalone]

#1505

In article <4f6960ba-9ead-4d3d-9955-6f3fc3a10f43@googlegroups.com>,
Howard - FM Pro Solutions <fmprosolutions@gmail.com> wrote:
> On Wednesday, November 13, 2013 9:47:36 AM UTC-8, Charles H. Sampson wrote:
> > Howard - FM Pro Solutions <fmprosolutions@gmail.com> wrote:
> > 
> > > If you have an UNSTORED (calc field) value, then it will automatically
> > > update itself whenever one of its dependencies are changed.  If you want a
> > > STORED dependent field to change, then you'll need to somehow
> > > force-trigger that change through a script or sometimes through use of the
> > > Evaluate() function with dependencies specified.
> > 
> >      The true believers in FileMaker seem to accept this the way of the
> > world. Here's what I, as a long-time designer and implementer of systems
> > software, see. With FileMaker we have a piece of software that permits
> > users to say, "Here is a formula. I want the value of that formula to be
> > put in this location." The implementers of FileMaker then say, "Fine.
> > We'll do that for you sometimes and sometimes we'll put a value that has
> > nothing to do with your formula." The only word that describes such an
> > "implementation" is "absurd".
> 
> Those of us who understand how FIleMaker works are fine with doing it the
> "FileMaker way".  I'm not sure that's absurd; it's just reality.
> 
> But let's look at other databases. 
<snip>

I tried to use Access yesterday to make a very simple database that
needed to calculate the sum of data in related records (something that
would take less than five minutes in FileMaker to whip up) ... good
grief what an disgutingly hopeless pig of a system that is. In the end
I gave up wasting the time and went back to the old slower method in
Excel instead.

Helpful Harry  :o)

[toc] | [prev] | [next] | [standalone]

#1510

Howard - FM Pro Solutions <fmprosolutions@gmail.com> wrote:

> On Wednesday, November 13, 2013 9:47:36 AM UTC-8, Charles H. Sampson wrote:
> > Howard - FM Pro Solutions <fmprosolutions@gmail.com> wrote:
> > 
> > > If you have an UNSTORED (calc field) value, then it will automatically
> > > update itself whenever one of its dependencies are changed.  If you want a
> > > STORED dependent field to change, then you'll need to somehow
> > > force-trigger that change through a script or sometimes through use of the
> > > Evaluate() function with dependencies specified.
> 
> >      The true believers in FileMaker seem to accept this the way of the
> > world. Here's what I, as a long-time designer and implementer of systems
> > software, see. With FileMaker we have a piece of software that permits
> > users to say, "Here is a formula. I want the value of that formula to be
> > put in this location." The implementers of FileMaker then say, "Fine.
> > We'll do that for you sometimes and sometimes we'll put a value that has
> > nothing to do with your formula." The only word that describes such an
> > "implementation" is "absurd".
> 
> 
> Those of us who understand how FIleMaker works are fine with doing it the
> "FileMaker way".  I'm not sure that's absurd; it's just reality.

     As I said.

> But let's look at other databases.  SQL, in all its various flavors, is
> the most widely used database language, and as far as I know, none of the
> most popular flavors of SQL (MySql, MS-SQL, Oracle) have fields that fill
> in automatically with sums from other tables

     There's only one table in the database I'm working on.

>                                                -- at least not without a
> defined trigger, which I think is all I was suggesting in showing how you
> can use FileMaker to do the same.  SQL has "views", in which you can
> define such auto-calcs, but then why not just define the total within
> whatever UI you are using with that SQL.
> 
> And so back to FileMaker, you can use an unstored calc (defined as a
> field, but set to be unstored) to do what you want.  I'm not sure why
> that's absurd.

     It's absurd because the value of a field and its storage attributes
are totally independent concepts. Tying them together makes no sense.

>               But why even bother with a calc field when you are using a
> script anyhow to arrive at the layout you want to use? Why not add a small
> routine in that script to go to all records in a new, hidden window, grab
> the total, plug it into a global field or variable, and then display it on
> your UI layout?

     And what happens when one of the fields that this value depends on
is changed? According to the Pogue book, FileMaker Pro 8 is very limited
in the actions that you can attach a script to and committing a record
is not one of them. If I have to program every action in the database
using scripts, I can do that but I'll be very disappointed that
FileMaker doesn't take some of the burden from me.

>                 (In more current versions of FileMaker, you could also
> just make a quick SQL call within your script or unstored calc to grab the
> total for all records despite the current found set.)
> 
> Sorry if this doesn't help your understanding of FileMaker.

     It doesn't. Apology accepted. :-)

                        Charlie
-- 
Nobody in this country got rich on his own.  You built a factory--good.
But you moved your goods on roads we all paid for.  You hired workers we
all paid to educate. So keep a big hunk of the money from your factory.
But take a hunk and pay it forward.  Elizabeth Warren (paraphrased)

[toc] | [prev] | [next] | [standalone]

#1514

On 11/16/2013 12:01 AM, Charles H. Sampson wrote:
>>                But why even bother with a calc field when you are using a
>> >script anyhow to arrive at the layout you want to use? Why not add a small
>> >routine in that script to go to all records in a new, hidden window, grab
>> >the total, plug it into a global field or variable, and then display it on
>> >your UI layout?
>       And what happens when one of the fields that this value depends on
> is changed? According to the Pogue book, FileMaker Pro 8 is very limited
> in the actions that you can attach a script to and committing a record
> is not one of them. If I have to program every action in the database
> using scripts, I can do that but I'll be very disappointed that
> FileMaker doesn't take some of the burden from me.
>

It's been many years since I've fired up FileMaker 8, but I'm pretty 
sure they had script triggers in 8 and, if so, then OnCommit was 
certainly one of them from the start.

[toc] | [prev] | [next] | [standalone]

#1515

In article <l68ttp$8e3$1@news.motzarella.org>, Howard Schlossberg
<howard@nospam.fmprosolutions.com> wrote:

> On 11/16/2013 12:01 AM, Charles H. Sampson wrote:
> >>                But why even bother with a calc field when you are using a
> >> >script anyhow to arrive at the layout you want to use? Why not add a small
> >> >routine in that script to go to all records in a new, hidden window, grab
> >> >the total, plug it into a global field or variable, and then display it on
> >> >your UI layout?
> >       And what happens when one of the fields that this value depends on
> > is changed? According to the Pogue book, FileMaker Pro 8 is very limited
> > in the actions that you can attach a script to and committing a record
> > is not one of them. If I have to program every action in the database
> > using scripts, I can do that but I'll be very disappointed that
> > FileMaker doesn't take some of the burden from me.
> 
> It's been many years since I've fired up FileMaker 8, but I'm pretty 
> sure they had script triggers in 8 and, if so, then OnCommit was 
> certainly one of them from the start.

I think you're wasting your time. Charles simply wants to whine about
how "bad" FileMaker is, rather than using the answers to his question
that we give him. I certainly won't be bothering to try to answer any
more of them.

Helpful Harry  :o)

[toc] | [prev] | [next] | [standalone]

#1516

Helpful Harry <HelpfulHarry@BusyWorking.com> wrote:

> In article <l68ttp$8e3$1@news.motzarella.org>, Howard Schlossberg
> <howard@nospam.fmprosolutions.com> wrote:
> 
> I think you're wasting your time. Charles simply wants to whine about
> how "bad" FileMaker is, rather than using the answers to his question
> that we give him. I certainly won't be bothering to try to answer any
> more of them.

     Thank you!

                        Charlie
-- 
Nobody in this country got rich on his own.  You built a factory--good.
But you moved your goods on roads we all paid for.  You hired workers we
all paid to educate. So keep a big hunk of the money from your factory.
But take a hunk and pay it forward.  Elizabeth Warren (paraphrased)

[toc] | [prev] | [next] | [standalone]

#1517

Howard Schlossberg <howard@nospam.fmprosolutions.com> wrote:

> >>                But why even bother with a calc field when you are using a
> >> >script anyhow to arrive at the layout you want to use? Why not add a small
> >> >routine in that script to go to all records in a new, hidden window, grab
> >> >the total, plug it into a global field or variable, and then display it on
> >> >your UI layout?
> >       And what happens when one of the fields that this value depends on
> > is changed? According to the Pogue book, FileMaker Pro 8 is very limited
> > in the actions that you can attach a script to and committing a record
> > is not one of them. If I have to program every action in the database
> > using scripts, I can do that but I'll be very disappointed that
> > FileMaker doesn't take some of the burden from me.
> 
> It's been many years since I've fired up FileMaker 8, but I'm pretty 
> sure they had script triggers in 8 and, if so, then OnCommit was 
> certainly one of them from the start.

     This sounds promising. I'm trying to find out more about it but so
far not much luck. The Pogue book doesn't seem to mention it at all.
(I'm beginning to think I've relied too much on the Pogue book.)
FileMaker's help refers to a database that I'm looking at right now.

     Thanks for your help.

                        Charlie
-- 
Nobody in this country got rich on his own.  You built a factory--good.
But you moved your goods on roads we all paid for.  You hired workers we
all paid to educate. So keep a big hunk of the money from your factory.
But take a hunk and pay it forward.  Elizabeth Warren (paraphrased)

[toc] | [prev] | [next] | [standalone]

#1526

Charles H. Sampson <csampson@inetworld.net> wrote:

> Howard Schlossberg <howard@nospam.fmprosolutions.com> wrote:
> 
> > >>                But why even bother with a calc field when you are
> > >using a script anyhow to arrive at the layout you want to use? Why
> > >not add a small routine in that script to go to all records in a
> > >new, hidden window grab the total, plug it into a global field or
> > >variable, and then display it on your UI layout?

> > >And what happens when one of the fields that this value depends on is
> > >changed? According to the Pogue book, FileMaker Pro 8 is very limited
> > >in the actions that you can attach a script to and committing a record
> > >is not one of them. If I have to program every action in the database
> > >using scripts, I can do that but I'll be very disappointed that
> > >FileMaker doesn't take some of the burden from me.
> > 
> > It's been many years since I've fired up FileMaker 8, but I'm pretty
> > sure they had script triggers in 8 and, if so, then OnCommit was 
> > certainly one of them from the start.
> 
>      This sounds promising. I'm trying to find out more about it but so
> far not much luck. The Pogue book doesn't seem to mention it at all.
> (I'm beginning to think I've relied too much on the Pogue book.)
> FileMaker's help refers to a database that I'm looking at right now.

     No luck so far. The database that FileMaker referred to had to do
with Apple Events, nothing internal to FileMaker.

     You're saying that there is a way to trigger a script on committing
a record, right? If so, I'm beginning to think it came after FileMaker
Pro 8. Do you have a specific pointer?

     Thanks again for your help.

                        Charles
-- 
Nobody in this country got rich on his own.  You built a factory--good.
But you moved your goods on roads we all paid for.  You hired workers we
all paid to educate. So keep a big hunk of the money from your factory.
But take a hunk and pay it forward.  Elizabeth Warren (paraphrased)

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.databases.filemaker

csiph-web