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

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

Date Fields

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

Contents

  Date Fields jiriksova@gmail.com - 2013-12-17 13:03 -0800
    Re: Date Fields Martin Τrautmann <t-usenet@gmx.net> - 2013-12-17 21:27 +0000
      Re: Date Fields jiriksova@gmail.com - 2013-12-17 15:30 -0800
        Re: Date Fields Helpful Harry <HelpfulHarry@BusyWorking.com> - 2013-12-18 13:11 +1300
          Re: Date Fields jiriksova@gmail.com - 2013-12-17 17:26 -0800
          Re: Date Fields Martin Τrautmann <t-usenet@gmx.net> - 2013-12-18 05:24 +0000
            Re: Date Fields Helpful Harry <HelpfulHarry@BusyWorking.com> - 2013-12-18 19:24 +1300
              Re: Date Fields Martin Τrautmann <t-usenet@gmx.net> - 2013-12-18 06:55 +0000
                Re: Date Fields Helpful Harry <HelpfulHarry@BusyWorking.com> - 2013-12-19 18:48 +1300
                  Re: Date Fields Martin Τrautmann <t-usenet@gmx.net> - 2013-12-19 07:16 +0000
                    Re: Date Fields Howard Schlossberg <howard@nospam.fmprosolutions.com> - 2013-12-19 09:30 -0800
                      Re: Date Fields Martin Τrautmann <t-usenet@gmx.net> - 2013-12-19 18:26 +0000
                        Re: Date Fields Howard Schlossberg <howard@nospam.fmprosolutions.com> - 2013-12-19 11:45 -0800
                          Re: Date Fields Martin Τrautmann <t-usenet@gmx.net> - 2013-12-19 20:05 +0000

#1594 — Date Fields

I have two date fields: Project_start_date and Project_finish_date and one calculated field Project_status. Project is either NotStartedYet, InProgress, or Finished.

Date fields do not sometime trigger the correct Project Status. For example, a project starts Nov 1, 2013, project finish value is Jun 1, 2014, and today is Dec 17, 2013, but a calculated Project Status shows a value NotStartedYet. But when I copy the value of StartDate field, clear the field, and paste the value back into the field, ProjectStatus value is re-calculated correctly to be InProgress. The finish date sometimes triggers the same behavior.

What am I doing wrong?

Thanks for any suggestion or advice


George

[toc] | [next] | [standalone]

#1595

On Tue, 17 Dec 2013 13:03:33 -0800 (PST), jiriksova@gmail.com wrote:
>  I have two date fields: Project_start_date and Project_finish_date and one calculated field Project_status. Project is either NotStartedYet, InProgress, or Finished.
> 
>  Date fields do not sometime trigger the correct Project Status. For example, a project starts Nov 1, 2013, project finish value is Jun 1, 2014, and today is Dec 17, 2013, but a calculated Project Status shows a value NotStartedYet. But when I copy the value of StartDate field, clear the field, and paste the value back into the field, ProjectStatus value is re-calculated correctly to be InProgress. The finish date sometimes triggers the same behavior.
> 
>  What am I doing wrong?
> 
>  Thanks for any suggestion or advice

Is the status unstored?
Does it calculate on empty fields?

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

#1597

On Tuesday, December 17, 2013 3:27:23 PM UTC-6, Martin Τrautmann wrote:
> On Tue, 17 Dec 2013 13:03:33 -0800 (PST), jiriksova@gmail.com wrote:
> 
> >  I have two date fields: Project_start_date and Project_finish_date and one calculated field Project_status. Project is either NotStartedYet, InProgress, or Finished.
> 
> > 
> 
> >  Date fields do not sometime trigger the correct Project Status. For example, a project starts Nov 1, 2013, project finish value is Jun 1, 2014, and today is Dec 17, 2013, but a calculated Project Status shows a value NotStartedYet. But when I copy the value of StartDate field, clear the field, and paste the value back into the field, ProjectStatus value is re-calculated correctly to be InProgress. The finish date sometimes triggers the same behavior.
> 
> > 
> 
> >  What am I doing wrong?
> 
> > 
> 
> >  Thanks for any suggestion or advice
> 
> 
> 
> Is the status unstored?
> 
> Does it calculate on empty fields?

Status calculation is stored. No status is calculated if either or both date fields are empty.

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

#1598

In article <76651a66-69d3-4c19-bedc-6e644872a89c@googlegroups.com>,
<jiriksova@gmail.com> wrote:
> On Tuesday, December 17, 2013 3:27:23 PM UTC-6, Martin Ԥrautmann wrote:
> > On Tue, 17 Dec 2013 13:03:33 -0800 (PST), jiriksova@gmail.com wrote:
> > > 
> > >  I have two date fields: Project_start_date and Project_finish_date and
> > >  one calculated field Project_status. Project is either NotStartedYet,
> > >  InProgress, or Finished.
> > > 
> > >  Date fields do not sometime trigger the correct Project Status. For
> > >  example, a project starts Nov 1, 2013, project finish value is Jun 1,
> > >  2014, and today is Dec 17, 2013, but a calculated Project Status shows a
> > >  value NotStartedYet. But when I copy the value of StartDate field, clear
> > >  the field, and paste the value back into the field, ProjectStatus value
> > >  is re-calculated correctly to be InProgress. The finish date sometimes
> > >  triggers the same behavior.
> > > 
> > >  What am I doing wrong?
> > > 
> > >  Thanks for any suggestion or advice
> > 
> > Is the status unstored?
> > 
> > Does it calculate on empty fields?
> 
> Status calculation is stored. No status is calculated if either or both 
> date fields are empty.

Calculation Fields that you want to automatically update should always
be Unstored. That way Filemaker recalculates it every time the field is
used (on-screen, printouts, other calculations, exports, etc.).

In most circumstances Stored calculations make no sense (auto-enter and
scripted calculations are usually better options for stored results),
and FileMaker's default should really be Unstored.

Helpful Harry  :o)

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

#1599

On Tuesday, December 17, 2013 6:11:27 PM UTC-6, Helpful Harry wrote:
> In article <76651a66-69d3-4c19-bedc-6e644872a89c@googlegroups.com>,
> 
> <jiriksova@gmail.com> wrote:
> 
> > On Tuesday, December 17, 2013 3:27:23 PM UTC-6, Martin ��rautmann wrote:
> 
> > > On Tue, 17 Dec 2013 13:03:33 -0800 (PST), jiriksova@gmail.com wrote:
> 
> > > > 
> 
> > > >  I have two date fields: Project_start_date and Project_finish_date and
> 
> > > >  one calculated field Project_status. Project is either NotStartedYet,
> 
> > > >  InProgress, or Finished.
> 
> > > > 
> 
> > > >  Date fields do not sometime trigger the correct Project Status. For
> 
> > > >  example, a project starts Nov 1, 2013, project finish value is Jun 1,
> 
> > > >  2014, and today is Dec 17, 2013, but a calculated Project Status shows a
> 
> > > >  value NotStartedYet. But when I copy the value of StartDate field, clear
> 
> > > >  the field, and paste the value back into the field, ProjectStatus value
> 
> > > >  is re-calculated correctly to be InProgress. The finish date sometimes
> 
> > > >  triggers the same behavior.
> 
> > > > 
> 
> > > >  What am I doing wrong?
> 
> > > > 
> 
> > > >  Thanks for any suggestion or advice
> 
> > > 
> 
> > > Is the status unstored?
> 
> > > 
> 
> > > Does it calculate on empty fields?
> 
> > 
> 
> > Status calculation is stored. No status is calculated if either or both 
> 
> > date fields are empty.
> 
> 
> 
> Calculation Fields that you want to automatically update should always
> 
> be Unstored. That way Filemaker recalculates it every time the field is
> 
> used (on-screen, printouts, other calculations, exports, etc.).
> 
> 
> 
> In most circumstances Stored calculations make no sense (auto-enter and
> 
> scripted calculations are usually better options for stored results),
> 
> and FileMaker's default should really be Unstored.
> 
> 
> 
> Helpful Harry  :o)

Thank you Harry. I changed to Unstored, and the problem disappeared. I should have known this for a long time. Thanks again

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

#1601

On Wed, 18 Dec 2013 13:11:27 +1300, Helpful Harry wrote:
> > > Is the status unstored?
> > > 
> > > Does it calculate on empty fields?
> > 
> > Status calculation is stored. No status is calculated if either or both 
> > date fields are empty.
> 
>  Calculation Fields that you want to automatically update should always
>  be Unstored. That way Filemaker recalculates it every time the field is
>  used (on-screen, printouts, other calculations, exports, etc.).

I prefer stored fields. They display faster, especially on list and
table views. And they are much faster for find operations.

>  In most circumstances Stored calculations make no sense (auto-enter and
>  scripted calculations are usually better options for stored results),
>  and FileMaker's default should really be Unstored.

I don't see any need for most circumstances. I use them mainly while
using data from tables within other files, where I feel that update
triggers are sometimes unreliable.

In this case here I suppose that the other choice would have helped:
calculate on empty fields.

- Martin

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

#1603

In article <slrnlb2cck.1np6.t-usenet@ID-685.user.individual.de>, Martin
Ԥrautmann <t-usenet@gmx.net> wrote:

> On Wed, 18 Dec 2013 13:11:27 +1300, Helpful Harry wrote:
> > > > Is the status unstored?
> > > > 
> > > > Does it calculate on empty fields?
> > > 
> > > Status calculation is stored. No status is calculated if either or both 
> > > date fields are empty.
> > 
> >  Calculation Fields that you want to automatically update should always
> >  be Unstored. That way Filemaker recalculates it every time the field is
> >  used (on-screen, printouts, other calculations, exports, etc.).
> 
> I prefer stored fields. They display faster, especially on list and
> table views. And they are much faster for find operations.

They will be, but the problem is that they often show the incorrect /
out-dated data. 

It's like setting an Excel spreadsheet to not recalculate automatically
and then changing some of the cell information, and then taking an hour
to figure out why the total is wrong. (In Excel, the recalculating
option was created during the days of slow computers, so you could
change all the cells you wanted, and then re-calculate in one go ...
but it's pretty irrelevant in these days of fast computers.)

Helpful Harry  :o)

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

#1604

On Wed, 18 Dec 2013 19:24:24 +1300, Helpful Harry wrote:
> > I prefer stored fields. They display faster, especially on list and
> > table views. And they are much faster for find operations.
> 
>  They will be, but the problem is that they often show the incorrect /
>  out-dated data. 

Often? I use them very much, and when they show incorrect or outdated
data it's usually the designer's fault.

Where and when do you observe incorrect data?

>  It's like setting an Excel spreadsheet to not recalculate automatically
>  and then changing some of the cell information, and then taking an hour
>  to figure out why the total is wrong. (In Excel, the recalculating
>  option was created during the days of slow computers, so you could
>  change all the cells you wanted, and then re-calculate in one go ...
>  but it's pretty irrelevant in these days of fast computers.)

That's a very different kind of problem - there you can't rely on the
calculation.

The major problem with calculations which I did not solve yet are
recursive fields and auto-enter data to itself, such as

  field y: if (isnumber(rightwords(x,1)),rightwords(x,1),y)
  field x: if (rightwords(x,1) equals y, leftwords(x,wordcount(x)-1), x)

When I enter "A 1" to x then y becomes "1", but x remains "A 1".

I do need extra steps for data triggering, or I'd need extra fields.

- Martin

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

#1609

In article <slrnlb2hlv.1np6.t-usenet@ID-685.user.individual.de>, Martin
Ԥrautmann <t-usenet@gmx.net> wrote:
> On Wed, 18 Dec 2013 19:24:24 +1300, Helpful Harry wrote:
> > >
> > > I prefer stored fields. They display faster, especially on list and
> > > table views. And they are much faster for find operations.
> > 
> >  They will be, but the problem is that they often show the incorrect /
> >  out-dated data. 
> 
> Often? I use them very much, and when they show incorrect or outdated
> data it's usually the designer's fault.

Yep, because they didn't set the field to be Unstored.  ;o)



> Where and when do you observe incorrect data?

Every time you change the source data and the stored calculation
retains the old value rather than recalculate to the correct new value
... as in the original posted problem.

I didn't say stored values don't have any use, but most of the time you
do want a Calculation field to actually calculate.

Helpful Harry  :o)

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

#1611

On Thu, 19 Dec 2013 18:48:50 +1300, Helpful Harry wrote:
> > Where and when do you observe incorrect data?
> 
>  Every time you change the source data and the stored calculation
>  retains the old value rather than recalculate to the correct new value
>  ... as in the original posted problem.
> 
>  I didn't say stored values don't have any use, but most of the time you
>  do want a Calculation field to actually calculate.

So my experience is different to yours: calculations do work pretty
reliable here. It's a disaster if they wouldn't - and to my experience
this does not happen very often.

I'd like to see the cross check of the other option: calculate on empty
fields. I'd guess this would work, too.

You may fix the one fault via the other fault. Or you could make it
right ;-)

- Martin

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

#1612

On 12/18/2013 11:16 PM, Martin Τrautmann wrote:
> On Thu, 19 Dec 2013 18:48:50 +1300, Helpful Harry wrote:
>>> Where and when do you observe incorrect data?
>>
>>   Every time you change the source data and the stored calculation
>>   retains the old value rather than recalculate to the correct new value
>>   ... as in the original posted problem.
>>
>>   I didn't say stored values don't have any use, but most of the time you
>>   do want a Calculation field to actually calculate.
>
> So my experience is different to yours: calculations do work pretty
> reliable here. It's a disaster if they wouldn't - and to my experience
> this does not happen very often.
>
> I'd like to see the cross check of the other option: calculate on empty
> fields. I'd guess this would work, too.
>
> You may fix the one fault via the other fault. Or you could make it
> right ;-)

Stored calculations should be reliable unless:
- it references a field from a related table, and the value of that 
field has changed;
- it references a function that provides its own value without reference 
to any fields, and that value is changed -- for example Get(CurrentDate).

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

#1613

On Thu, 19 Dec 2013 09:30:11 -0800, Howard Schlossberg wrote:
>  Stored calculations should be reliable unless:
>  - it references a field from a related table, and the value of that 
>  field has changed;
>  - it references a function that provides its own value without reference 
>  to any fields, and that value is changed -- for example Get(CurrentDate).

Both of these would not apply within the examples here.

And relations usually work. I only observed problems when relations
worked across files. And, of course, it may be more of a problem for one
to many relations - even for unstored calculations.

- Martin

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

#1614

On 12/19/2013 10:26 AM, Martin Τrautmann wrote:
> On Thu, 19 Dec 2013 09:30:11 -0800, Howard Schlossberg wrote:
>>   Stored calculations should be reliable unless:
>>   - it references a field from a related table, and the value of that
>>   field has changed;
>>   - it references a function that provides its own value without reference
>>   to any fields, and that value is changed -- for example Get(CurrentDate).
>
> Both of these would not apply within the examples here.
>
> And relations usually work. I only observed problems when relations
> worked across files. And, of course, it may be more of a problem for one
> to many relations - even for unstored calculations.

If you are referring to the problem of the OP, then it could apply.  Or 
rather, I should add another exception.

The OP said:
> Date fields do not sometime trigger the correct Project Status. For example, a project starts Nov 1, 2013, project finish value is Jun 1, 2014, and today is Dec 17, 2013, but a calculated Project Status shows a value NotStartedYet. But when I copy the value of StartDate field, clear the field, and paste the value back into the field, ProjectStatus value is re-calculated correctly to be InProgress. The finish date sometimes triggers the same behavior.

So if the field referenced in the stored calc (in this case, the 
StartDate) is itself a lookup or auto-enter calc based on yet another 
field...then the stored calc in question may not update itself.

Howard

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

#1615

On Thu, 19 Dec 2013 11:45:40 -0800, Howard Schlossberg wrote:
> > Both of these would not apply within the examples here.
> >
> > And relations usually work. I only observed problems when relations
> > worked across files. And, of course, it may be more of a problem for one
> > to many relations - even for unstored calculations.
> 
>  If you are referring to the problem of the OP, then it could apply.  Or 
>  rather, I should add another exception.

I just built a sample database with such a verification. When I use both
a stored and unstored calculation, based on the same formula, the
results are the same.

However, the IsEmpty(date field) might be the wrong check. I used a
check of (date field > 1) check instead.

>  The OP said:
> > Date fields do not sometime trigger the correct Project Status. For example, a project starts Nov 1, 2013, project finish value is Jun 1, 2014, and today is Dec 17, 2013, but a calculated Project Status shows a value NotStartedYet. But when I copy the value of StartDate field, clear the field, and paste the value back into the field, ProjectStatus value is re-calculated correctly to be InProgress. The finish date sometimes triggers the same behavior.
> 
>  So if the field referenced in the stored calc (in this case, the 
>  StartDate) is itself a lookup or auto-enter calc based on yet another 
>  field...then the stored calc in question may not update itself.

The calculation is a text field. The date fields are ... date fields...

So I doubt that this is a self reference here. And it was not the
assumption that the StartDate did work incorrectly.

- Martin

[toc] | [prev] | [standalone]

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

csiph-web