Strange Find result

[ron G]

I am using FM 11 03 ADVANCED ON OSX

I have produced a report with Sub Summary grouping that works and looks like this:

In order to show just the current months 'activity' there is a field called Date_Progress which holds the most recent months activity date.

This works unless I go back to the member record and change the date. In the example above, David Crocket had a Date_Progress of April 17, 2011 prior to being changed to Mar 17, 2011. After the change, even though the Date_Progress field shows the correct date, the Find Script somehow still 'sees' the April 17, 2011 date. Huh?

Here is the script:

Here is an update: IF I MAKE THE DATE CHANGE, CLOSE THE DATABASE, REOPEN IT AND RUN THE REPORT, EVERYTHING WORKS AS EXPECTED. So, "How can I simulate that?"

I've been working this problem for 2 days and have run out of ideas. Your help is appreciated.

[comment]

Hard to say without seeing the restored requests and understanding the context. Are you searching related fields?

[IT_User]

Here is an update: IF I MAKE THE DATE CHANGE, CLOSE THE DATABASE, REOPEN IT AND RUN THE REPORT, EVERYTHING WORKS AS EXPECTED. So, "How can I simulate that?"

I've been working this problem for 2 days and have run out of ideas. Your help is appreciated.

Use the script command Refresh Window.

Or if that doesn't work use Commit Record then Refresh Window.

[ron G]

Use the script command Refresh Window.

Or if that doesn't work use Commit Record then Refresh Window.

Thanks for the reply. I added the 2 commands above. They 'seemed' to work until I used gtrr to goto a candidate record, change the date (Date_Progress) and then 'rexecute' the start and stop date filters.

Here is the setup:

I have a Candidate window with the Candidate information.

I have a Report (Also based on Candidate) that opens in a 2nd window.

On the report, I have GTRR button that takes me to the Candidate Window and the relevant candidate record. If I change the Date_Progress field on the Candidate window, IT SHOWS as changed in the Report window.

But, if I 'filter' the values by adding 'startdate' and 'stopdate' values to the calendar fields and run the 'find' script indicated above, the changed Report record is still INCLUDED. It seems as if FM is seeing the old Date_Progress value when I can see that it has clearly been changed. huh?

For example, David Crocket has a Date_Progress date of Apr 11 2011. I can run the report with start date of Apr 1 2011 and stop date of Apr 30 2011 and he shows. But, if I goto his record and change the date to Mar 11 2011 and then rerun the report with the same start and stop dates, he CONTINUES to show for April? Only when I close the database and reopen it will he show as a March Date_Progress.

[IT_User]

Thanks for the reply. I added the 2 commands above. They 'seemed' to work until I used gtrr to goto a candidate record, change the date (Date_Progress) and then 'rexecute' the start and stop date filters.

Did you try it with Flush cached join results checked? That usually helps when dealing with a GtRR step. You can also specify which window is being refreshed.

Here is the setup:

I have a Candidate window with the Candidate information.

I have a Report (Also based on Candidate) that opens in a 2nd window.

On the report, I have GTRR button that takes me to the Candidate Window and the relevant candidate record. If I change the Date_Progress field on the Candidate window, IT SHOWS as changed in the Report window.

But, if I 'filter' the values by adding 'startdate' and 'stopdate' values to the calendar fields and run the 'find' script indicated above, the changed Report record is still INCLUDED. It seems as if FM is seeing the old Date_Progress value when I can see that it has clearly been changed. huh?

I might have the same question as "Comment" has. Or how the relation table looks.

[ron G]

Did you try it with Flush cached join results cached? That usually helps when dealing with a GtRR step. You can also specify which window is being refreshed.

I might have the same question as "Comment" has. Or how the relation table looks.

Thanks for the suggestion.

Since I have 2 windows open: (Candidate and Report) I can bypass the gtrr script and just click on the Candidate window, make the date change (Date_Progress) and see the changed date in the Report window.

But, when I run the EXECUTE script (from the Execute button) does the FIND somehow pickup the PRIOR VALUE of the Date_Progress field. Very perplexing....???

[Vaughan]

Explain more about this Date Progress field. Fields cannot "remember" previous values. Is it a calculation field?

[ron G]

Explain more about this Date Progress field. Fields cannot "remember" previous values. Is it a calculation field?

As a member 'progresses' through the various stages of membership, as each 'stage' is attained, Date_Progress is updated (via script) to show the most recent date.

It is a regular date field that as you can see above, gets changed correctly and shows as being changed. The problem is that although the Date_Progress field gets visibly changed, the 'find' somehow picks the previous value of the Date_Progress field. How can this be?

Again, the only way I can get the 'find' script to work is to close the application, reopen it and rerun the find script (see above). I suspect this is NOT a FM 'feature'... :)

[ron G]

As a member 'progresses' through the various stages of membership, as each 'stage' is attained, Date_Progress is updated (via script) to show the most recent date.

It is a regular date field that as you can see above, gets changed correctly and shows as being changed. The problem is that although the Date_Progress field gets visibly changed, the 'find' somehow picks the previous value of the Date_Progress field. How can this be?

Again, the only way I can get the 'find' script to work is to close the application, reopen it and rerun the find script (see above). I suspect this is NOT a FM 'feature'...

Above is the output report after I changed David Crockett's from April to March. The weird thing is that when I perform the search on the date range April 1 - Apr 30 Crockett's March record continues to be included. Why? Or, How do I 'stop this'?

[Vaughan]

Post the file.

[ron G]

Post the file.

Ok

Here is the file.

When it opens, just goto the MEMBERSHIP TAB. THE instructions to duplicate the problem are therein.

Thank you.

Membership.fp7.zip

[Vaughan]

The stored find criteria in the Perform Find and Constrain Find steps cannot evaluate variables.

Instead, change into Find mode and use set field to enter the criteria, the perform the find without restore:

Enter Find Mode []

Set Field [ Date_Progress ; Global::gStartDate & "..." & Global::gStartDate ]

Perform Find []

Cudos to *Comment, he had the issue identified on 23 June:

Hard to say without seeing the restored requests and understanding the context.

[ron G]

The stored find criteria in the Perform Find and Constrain Find steps cannot evaluate variables.

Instead, change into Find mode and use set field to enter the criteria, the perform the find without restore:

Enter Find Mode []

Set Field [ Date_Progress ; Global::gStartDate & "..." & Global::gStartDate ]

Perform Find []

Cudos to *Comment, he had the issue identified on 23 June:

Thanks for the reply.

Going to FIND mode and using set field to enter the criteria begs the question "Why does my method work until I change a record and then work again when I reopen the table?" Shouldn't it either work or not work consistently?

[bruceR]

Thanks for the reply.

Going to FIND mode and using set field to enter the criteria begs the question "Why does my method work until I change a record and then work again when I reopen the table?" Shouldn't it either work or not work consistently?

You never commit the record.

I think we have talked about this before.

On the Members layout, use conditional formatting to highlight an object when get( recordOpenState) > 0

Change the initiated date. Note that the member record is still open. Your "Initiated Date Check" script trigger script does not commit it.

[ron G]

You never commit the record.

I think we have talked about this before.

On the Members layout, use conditional formatting to highlight an object when get( recordOpenState) > 0

Change the initiated date. Note that the member record is still open. Your "Initiated Date Check" script trigger script does not commit it.

Thanks for the reply Bruce. My script DOES include a COMMIT RECORD/REQUEST script step prior to doing the find but it doesn't seem to commit. Or, is there another 'commit' command I am missing?

I just noticed, $G_StartDate and $G_EndDate show in the Debugger as 4/1/2011 and 4/30/2011. Aren't those the values that FIND should use when executed?

[Vaughan]

I just noticed, $G_StartDate and $G_EndDate show in the Debugger as 4/1/2011 and 4/30/2011. Aren't those the values that FIND should use when executed?

Put an exit script step after the first Perform Find. Then manually issue a Modify Last Find and see what actually got entered.

[bruceR]

Thanks for the reply Bruce. My script DOES include a COMMIT RECORD/REQUEST script step prior to doing the find but it doesn't seem to commit. Or, is there another 'commit' command I am missing?

I just noticed, $G_StartDate and $G_EndDate show in the Debugger as 4/1/2011 and 4/30/2011. Aren't those the values that FIND should use when executed?

"Or, is there another 'commit' command I am missing?"

I was very explicit.

Change the initiated date. Note that the member record is still open.

Your "Initiated Date Check" script trigger script does not commit it.

>>FIX the Initiated Date Check script.<<

You cannot commit a record in one window that is open in another window.

[bruceR]

[bruceR]

Change initiated date and view results in this file. Then enable COMMIT step at end of modified "Initiated Date Check" script and try again.

Membership.zip

[ron G]

Change initiated date and view results in this file. Then enable COMMIT step at end of modified "Initiated Date Check" script and try again.

Membership.zip

Perfect! Thank you verrry much Bruce! The use of the Conditional Formatting 'bar' really drove home your point.

This is what I get from the lesson:

Although I can 'see' the changed record, FM, when doing a FIND, looks ONLY at committed records and the 'seen' record, although changed, is only changed in FM memory. This explains the 'seeing but not recognizing' phenomenon I experienced.

Do I get it?