FIND not accurate?

#1

FMP 8.5

For one of my clients, we have a calculated field "Pending" that
depends on values of calculated fields in other tables, etc.... in
other words it's a fairly complex calculation. However, the result in
"Pending" is only either 0 or 1.

When I perform a find on "pending" for 1...... I get a found set that
includes a lot of 1s but some 0s as well.

I first noticed this when the find was performed from a script, but it
happens when I do it manually too.

The calculation itself is behaving correctly, but not the find performed
ON the calculation.

Any thoughts?

Thanks,
Greg

#2

Generally speaking it's because one would use that calculation directly in the find mode, which is wrong as in Find mode any calculation is empty. So the way to do a proper 'find' is first to 'Set Field' your calculation into a global, and than 'find' from that 'global'.
Remi-Noel

"Greg Dember" <greg (AT) artocratic (DOT) com> a écrit dans le message de news: greg-FD4E48.06545231012007 (AT) bubb...T) drizzle.com...

Quote:

FMP 8.5

For one of my clients, we have a calculated field "Pending" that
depends on values of calculated fields in other tables, etc.... in
other words it's a fairly complex calculation. However, the result in
"Pending" is only either 0 or 1.

When I perform a find on "pending" for 1...... I get a found set that
includes a lot of 1s but some 0s as well.

I first noticed this when the find was performed from a script, but it
happens when I do it manually too.

The calculation itself is behaving correctly, but not the find performed
ON the calculation.

Any thoughts?

Thanks,
Greg

#3

Greg-

1) Is this a calculation field or a non-calc field set to Auto Enter a
calculation?
2) If a calc field, is it set to return a Number result? If non-calc
is it a Number field?
3) Is the 'Context' of the calculation (ie the TO it is based in) the
same as the TO that the layout is based on? The same as the field
your searching on?

I'm not sure Remi has fully understood your situation, but she's right
in that a

###
Enter Find Mode
Set Field -- Criteria
Perform Find
###

is a better way of constructing a scripted Find than using

###
Perform Find -- Criteria.
##

If none of this helps (my guess it's a context issue) then try posting
the whole calc with some more background.

G

On Jan 31, 7:54 am, Greg Dember <g... (AT) artocratic (DOT) com> wrote:

Quote:

FMP 8.5

For one of my clients, we have a calculated field "Pending" that
depends on values of calculated fields in other tables, etc.... in
other words it's a fairly complex calculation. However, the result in
"Pending" is only either 0 or 1.

When I perform a find on "pending" for 1...... I get a found set that
includes a lot of 1s but some 0s as well.

I first noticed this when the find was performed from a script, but it
happens when I do it manually too.

The calculation itself is behaving correctly, but not the find performed
ON the calculation.

Any thoughts?

Thanks,
Greg

#4

I would recommend following all of Grip's suggestions, followed by
Martin's reindexing suggestion.

The behavior you describe also sounds like bad indexing behavior that
was found in 8.0v1 and 8.0v2. Are you sure the machine(s) that have
this problem are indeed on 8.5? And if this is a served solution, are
you sure you have the latest FMS updaters installed?

Greg Dember wrote:

Quote:

FMP 8.5

For one of my clients, we have a calculated field "Pending" that
depends on values of calculated fields in other tables, etc.... in
other words it's a fairly complex calculation. However, the result in
"Pending" is only either 0 or 1.

When I perform a find on "pending" for 1...... I get a found set that
includes a lot of 1s but some 0s as well.

I first noticed this when the find was performed from a script, but it
happens when I do it manually too.

The calculation itself is behaving correctly, but not the find performed
ON the calculation.

Any thoughts?

Thanks,
Greg

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg (818) 883-2846
FM Professional Solutions, Inc. Los Angeles

FileMaker 8 Certified Developer
Associate Member, FileMaker Solutions Alliance

#5

My answers:

It is a calculation field
Set to return a number result
Context of calculation IS same as TO of layout

Result is unstored (it has to be)
Result is based on fields in other tables within same file
result is indexed when necessary because it is unstored

This is not related to how I invoke the find in a script step.... same
problem occurs when I perform the find manually.

NEW INFO!!!

Between the time I posted originally, and now, it is behaving correctly.
I suspect this has to do with the index getting updated as part of
housekeeping because of opening and closing "Define Database" or
something like that. I have noticed this pattern before.

Is there anything I can do programmatically, to ensure that the index is
updated, so that it will behave properly for my clients withhout me
having to monkey around?

Thanks!

Greg

Grip asked:

Quote:

1) Is this a calculation field or a non-calc field set to Auto Enter a
calculation?
2) If a calc field, is it set to return a Number result? If non-calc
is it a Number field?
3) Is the 'Context' of the calculation (ie the TO it is based in) the
same as the TO that the layout is based on? The same as the field
your searching on?

and Martin asked:

In article <slrnes1fo7.5a1.t-use (AT) ID-685 (DOT) user.individual.de>,
Martin Trautmann <t-use (AT) gmx (DOT) net> wrote:

Quote:

I don't understand the answer. Thus I don't know whether it's actually
correct.

From my understanding:

* is the result stored or unstored or an automatic field value from
computation?

* is the result based of tables within the same file or from other files?

* is the result indexed or unindexed?

My first guess would be to disable the index, then turning index on
again in order to force a re-indexing of a possibly corrupted index.

A second attempt might be a new field of type number, where you
copy/paste the calculation formula to the auto-enter and update this
field by either a replace operation of by updating one of the source
fields with its own contents (e.g. result = a+b: goto field a and
replace its contents by the result of a).

"Greg Dember" <greg (AT) artocratic (DOT) com> a ?crit dans le message de news:
greg-FD4E48.06545231012007 (AT) bubb...T) drizzle.com...
FMP 8.5

For one of my clients, we have a calculated field "Pending" that
depends on values of calculated fields in other tables, etc.... in
other words it's a fairly complex calculation. However, the result in
"Pending" is only either 0 or 1.

When I perform a find on "pending" for 1...... I get a found set that
includes a lot of 1s but some 0s as well.

I first noticed this when the find was performed from a script, but it
happens when I do it manually too.

The calculation itself is behaving correctly, but not the find performed
ON the calculation.

#6

Quote:

I'm not sure Remi has fully understood your situation, but she (HE

)
is right ...partly
Grip

You are right, Grip, I still have FMPv 6 habits, hard to forget...
Sorry to have said - again - something pretty wrong myself in the 'new' (to me) FM8 environment.
Remi-Noel

---------Original messages ---------------

Quote:

I'm not sure Remi has fully understood your situation, but she's right

in that a

###
Enter Find Mode
Set Field -- Criteria
Perform Find
###

is a better way of constructing a scripted Find than using

###
Perform Find -- Criteria.
##
Grip

Quote:

....
The calculation itself is behaving correctly, but not the find performed
ON the calculation.
....

Greg

Quote:

Generally speaking it's because one would use that calculation directly in the find mode, which is wrong as in Find mode any calculation is empty. So the way to do a proper 'find' is first to 'Set Field' your calculation into a global, and than 'find' from that 'global'.

Remi-Noel

Quote:

#7

Old habits die hard, M. Menegaux. I'll tell you this, I converted
from 6 to 7 a year and a half ago and it's been fantastic. I highly
recommend it.
G

On Jan 31, 4:14 pm, "Remi-Noel Menegaux" <rnmenegaux_AT_free.fr>
wrote:

Quote:

I'm not sure Remi has fully understood your situation, but she (HE

)
is right ...partly
Grip

You are right, Grip, I still have FMPv 6 habits, hard to forget...
Sorry to have said - again - something pretty wrong myself in the 'new' (to me) FM8 environment.
Remi-Noel

---------Original messages ---------------

I'm not sure Remi has fully understood your situation, but she's right
in that a

###
Enter Find Mode
Set Field -- Criteria
Perform Find
###

is a better way of constructing a scripted Find than using

###
Perform Find -- Criteria.
##
Grip

...
The calculation itself is behaving correctly, but not the find performed
ON the calculation.

...
Greg

Generally speaking it's because one would use that calculation directly in the find mode, which is wrong as in Find mode any calculation is empty. So the way to do a proper 'find' is first to 'Set Field' your calculation into a global, and than 'find' from that 'global'.
Remi-Noel

#8

I'm a little confused by your terminology. When "Do not store.." is
checked, that means it's unstored. Indexing set to 'None' with 'Turn
indexing on...' checked means it's not indexed. You're saying it's
the former?

I'm not 100% on how Filemaker indexes, but I think an unstored field,
is, by definition, unindexed and the index is created as part of the
execution of the Find request. So indexing shouldn't be an issue. My
experience is also that such a find request can be excruitiating slow
(as it has to build the index) depending on the number or records,
relationships, and network environment.

G

On Jan 31, 12:32 pm, Greg Dember <g... (AT) artocratic (DOT) com> wrote:

Quote:

My answers:

It is a calculation field
Set to return a number result
Context of calculation IS same as TO of layout

Result is unstored (it has to be)
Result is based on fields in other tables within same file
result is indexed when necessary because it is unstored

This is not related to how I invoke the find in a script step.... same
problem occurs when I perform the find manually.

NEW INFO!!!

Between the time I posted originally, and now, it is behaving correctly.
I suspect this has to do with the index getting updated as part of
housekeeping because of opening and closing "Define Database" or
something like that. I have noticed this pattern before.

Is there anything I can do programmatically, to ensure that the index is
updated, so that it will behave properly for my clients withhout me
having to monkey around?

Thanks!

Greg

Grip asked:

1) Is this a calculation field or a non-calc field set to Auto Enter a
calculation?
2) If a calc field, is it set to return a Number result? If non-calc
is it a Number field?
3) Is the 'Context' of the calculation (ie the TO it is based in) the
same as the TO that the layout is based on? The same as the field
your searching on?

and Martin asked:

In article <slrnes1fo7.5a1.t-... (AT) ID-685 (DOT) user.individual.de>,
Martin Trautmann <t... (AT) gmx (DOT) net> wrote:

I don't understand the answer. Thus I don't know whether it's actually
correct.

From my understanding:

* is the result stored or unstored or an automatic field value from
computation?

* is the result based of tables within the same file or from other files?

* is the result indexed or unindexed?

My first guess would be to disable the index, then turning index on
again in order to force a re-indexing of a possibly corrupted index.

A second attempt might be a new field of type number, where you
copy/paste the calculation formula to the auto-enter and update this
field by either a replace operation of by updating one of the source
fields with its own contents (e.g. result = a+b: goto field a and
replace its contents by the result of a).

"Greg Dember" <g... (AT) artocratic (DOT) com> a ?crit dans le message de news:
greg-FD4E48.06545231012... (AT) bubbleator (DOT) drizzle.com...
FMP 8.5

For one of my clients, we have a calculated field "Pending" that
depends on values of calculated fields in other tables, etc.... in
other words it's a fairly complex calculation. However, the result in
"Pending" is only either 0 or 1.

When I perform a find on "pending" for 1...... I get a found set that
includes a lot of 1s but some 0s as well.

I first noticed this when the find was performed from a script, but it
happens when I do it manually too.

The calculation itself is behaving correctly, but not the find performed
ON the calculation.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

FIND not accurate?

comp.databases.filemaker comp.databases.filemaker

FIND not accurate? - 01-31-2007 , 08:54 AM

Re: FIND not accurate? - 01-31-2007 , 09:13 AM

Re: FIND not accurate? - 01-31-2007 , 10:05 AM

Re: FIND not accurate? - 01-31-2007 , 11:31 AM

Re: FIND not accurate? - 01-31-2007 , 01:32 PM

Re: FIND not accurate? - 01-31-2007 , 05:14 PM

Re: FIND not accurate? - 01-31-2007 , 07:48 PM

Re: FIND not accurate? - 01-31-2007 , 07:57 PM