Stuck with something...

[tightmf]

I need to check if a month has passed since the last time a script was triggered by the "file open" script.

So:

File open blah blah

Is condition a met?

Is condition b met?

Has 1 month (not 30 days) passed since last triggering?

If all yes then trigger "find tardy donations"

Probably simple but I can't get it.

Tia

Mike

[bcooney]

I'd add a flag calc field in a sys table that evals to 1 if it's time for the find tardy donations.

That calc would be something like:

flag_Donations =

if (

condition a =1 and

condition b =1 and

Date ( Month ( lastTriggerDate )+1 ; Day ( lastTriggerDate ) ; Year ( lastTriggerDate ) >= Get (currentdate);

1, 0)

Then put If (flag_Donations=1)

perform script "find tardy donations"

end if

at the end of the open script.

[LaRetta]

If you use this calculation, remember that it must be set to unstored in the storage options or it won't update. But I don't really see the need for a flag calculation field, since it can be checked within the startup script itself. So, instead of checking for value of 1 in flag calculation, use an If[] statement within the startup script as:

If [ condition a = 1 and condition b = 1 and

Date ( Month ( lastTriggerDate )+1 ; Day ( lastTriggerDate ) ; Year ( lastTriggerDate ) >= Get (currentdate) ) ]

Neither is there a need, either in a * calculation or script, to propose a result of 1 or 0 since a test itself produces a boolean result.

* If calculation, simply drop the If() or Case() portion and it automatically becomes boolean. An If[] script-step resolves to boolean anyway.

LaRetta

[David Jondreau]

Since it hasn't been made explicit yet, I'd add that the LastTriggerDate is a global date field.

When the trigger conditions are met, that date field would be reset to the current date.

[LaRetta]

Well, DJ, I wouldn't make it a global date field that gets reset after the script runs since (in multi-user) a global date (which is reset via script run) won't be there when the file is opened next. I would store as standard date in a preference file.

Then I would have all (or most) preferences mirrored as global calcs which are triggered by one trigger field which is set by script upon open (so Preference doesn't have to be attached to various table occurrences just to access the values).

[David Jondreau]

I wasn't thinking of a shared solution, so yes a global field wouldn't work. Then I'd make sure it as a non-global field in a single user Admin table.

I load prefs into $$ vars which has the limitation of being file specific. I'd never thought of using global calcs that way...interesting

I'm not sure how your reference to global calcs relates to the problem at hand. Can you elaborate?

[bcooney]

I understand that the flag field is not necessary. But, I often find that separating logic from a script helps in the long run. If I want to know if I need to run the "Donations" script, I can simply look at this flag.

I really don't feel that this should run in an Open Script anyway. I'd put a button on the Main Menu and maybe make it smart, so that it highlights if the flag=1.

I prefer explicit If() statements. It's one less level of abstraction for me.

[LaRetta]

I'm not sure how your reference to global calcs relates to the problem at hand. Can you elaborate?

Mike mentioned he wanted the test upon file open. But he didn't say which table the opening layout will be based upon. By having the LastRunDate stored in a standard field in Preference table and loaded in global calc (along with other values needed throughout a solution), Mike can just check the value from any table without need of a relationship (which is the power of globals).

I sometimes load global variables also, but those values must come from somewhere. If you trigger your global calcs upon start-up, you can use those pref values from anywhere at any time (only when NEEDED) and not burden your solution with loading them all at start-up or requiring your script to jump to your preference table to grab the values at all.

I understand that the flag field is not necessary. But, I often find that separating logic from a script helps in the long run.

But if you wish to modify or understand that functionality, you must look in two places (the calculation and the script). I find it simpler if the entire test resides in one place. I explain the logic in the comment right above the script-step. Placing the test within the script also eliminates a needless calculation flag field which only adds to field-definition clutter.

Regarding explicit If(), to each their own. But I want people to know that it is NOT required at all and it actually uses an evaluation. For most people, it is simple to remember boolean logic once having it explained. My purpose for mentioning it, is for those who want to save a worthless evaluation and learn boolean logic which most programmers understand and use daily.

As to whether it should run at start-up? Mike asked that it run at start-up. Sometimes I run this type of thing at start-up; sometimes I display in portal on main menu; heck, there are many options for display after the test has happened. Who is to say, without a lot more information, WHAT is most practical for him? He can ask further if he wants to move the display elsewhere but that doesn't change the basic need. :wink2:

[tightmf]

Thanks for all the help. I was wrapped up in trying to find a fancy workaround for the Dec to January problem. I missed that Jan 2008 is less than Jan 2009. LOL.