Case Statement Not Re-evaluating

[MikeyFM]

To break the problem down to it's simplest form, I have a case statement that looks at a field "Modified Today" and if the field is today return Active else return Inactive. Sounds easy, the problem starts tomorrow when the field never gets re-evaluated for Inactive.

I can unstore the field so it's get evaluated during browsing but I have a portal on a another database that looks up my active work but is empty due to the unstored field.

Any ideas? Below is the Case Statement:

Case(Modified Date = Today,"Active",

Order_Status = "Job In" , "Active",

Order_Status = "Progress" , "Active",

Order_Status = "Approved" , "Active",

Order_Status = "Reproof" , "Active",

Order_Status = "Quality Control" , "Active",

Order_Status = "Plating" , "Active",

Order_Status = "Shipping" , "Active",

"Inactive")

[comment]

Try it this way:

Case (

Order_Status = "Job In" , "Active",

Order_Status = "Progress" , "Active",

Order_Status = "Approved" , "Active",

Order_Status = "Reproof" , "Active",

Order_Status = "Quality Control" , "Active",

Order_Status = "Plating" , "Active",

Order_Status = "Shipping" , "Active",

"Inactive"

) & "¶" & Modified Date

Then in the other file, have a matching calculation =

"Active¶" & Status (CurrentDate)

[MikeyFM]

Sorry, I don't think this will work, what I want the portal to show is all status from "Job In" to "Shipping" and "Proof Out" only if modified date equals today.

Any Ideas?

[comment]

I want the portal to show is all status from "Job In" to "Shipping" and "Proof Out" only if modified date equals today.

Hm. That is somewhat different than your original calculation - that one returns "Active" when ModifiedDate equals today OR when Order_Status equals one of the specified categories.

Anyway, the principle is the same: shift the unstored part to the left side of the relationship. So in Orders, you can have:

Case (

Order_Status = "Job In"

or

Order_Status = "Progress"

or

Order_Status = "Approved"

or

Order_Status = "Reproof"

or

Order_Status = "Quality Control"

or

Order_Status = "Plating"

or

Order_Status = "Shipping" ,

Modified Date

)

and in the other file just:

Status (CurrentDate)

---

P.S. For both calculations, the result is of type Date.

Edited April 29, 2008 by Guest

[MikeyFM]

Maybe I am a knuckle head but I don't understand this case statement and what it is returning, looks like it's only returning the modified date, anyway I have attached the sample databases

Case (

Order_Status = "Job In"

or

Order_Status = "Progress"

or

Order_Status = "Approved"

or

Order_Status = "Reproof"

or

Order_Status = "Quality Control"

or

Order_Status = "Plating"

or

Order_Status = "Shipping" ,

Modified Date

)

Archive.zip

[comment]

Change the ActiveInactive calculation field to be stored - after all, that was the entire purpose of the exercise.

[MikeyFM]

So tomorrow a record with the status of Job In will no longer be viewed in the Portal since it stored todays date???

[comment]

Correct. If you wanted, you could make the field in the parent file a global and select which day to view (this is a good way to test the implementation).

Edited April 29, 2008 by Guest

[MikeyFM]

Thanks for your help but that will not work I will need to rethink my logic because what I need to see in the portal is "Job In" no matter the date and "Proof Out" only if modified today, see the logic break down?

[comment]

see the logic break down?

No. All I see the conditions being changed once again - but the same principle will still work.

Rethink your strategy, and when you are certain about your requirements, we can return to this - that is, if you do not succeed on your own, now that you know the basic approach.

[MikeyFM]

Does viewing a relationship through a portal cause a unstored field to be evaluated?

[comment]

I am not sure I understand your question. In any case, it's not a matter of triggering an evaluation of an unstored calculation. The matchfield on the right side of the relationship (i.e. the child, or the portal side) must be INDEXED in order for the relationship to work. An unstored calculation field cannot be indexed.