Set Field [YourTable::PrintCount ; YourTable::PrintCount + 1 ]
Is a script step that will increment your counter. This assumes that you always use a script for printing the report so that you can include this step in that print script.
Yeah, that's what I just figured out. Thanks :)
This may not be important on prints but if something happens you have no way of verifying the prints by a simple counter. If you lose power how do you know if the number 7 is the prior count or whether it incremented?
The best method is to have an Actions table (or even Printed table) and insert the date printed. Then you can just count the dates just as easily as you can grab the number from that field. This Actions table can hold many different types of actions as well ... mailings, phone calls ... and it can have a Category field to separate them and a Description, i.e. Printed Annual Report 2011, Mailed invites for Board of Directors meeting, etc. It provides a tracking, audit and informational resource.
Just a thought ...
I like the idea of an actions table, but since this example increments a counter in a field, that count would be retained in cases of an unfortunate event such as a power outage.
Any time you depend upon a script to increment, how do you know if it fired or not just by looking at a number in a field? You do not. I have encountered businesses and users using counters many times before and they cannot depend upon the number because there is no tracking of what it represents.
The power outage I am talking about is 1) if power fails right before the increment or 2) power fails after or 3) any other number of issues. By looking at the counter, did it update or not via script? YOu simply will not know if it didn't work unless you go to backup copy. Even then, you really will never know.
To say it another way, if the number is 3 what does that 3 represent? Did it print yesterday? YOu will not know.
Counters and tickers are very poor substitute when we can create a record as a counter which also holds valuable information of what the 'number' represents. If the item being counted is meaningless then counters and tickers are fine; otherwise create a record with a date of the action. It takes no more resource to script record creation than incrementing a field and the payoff is dependable statistics and added value.
Another example is using counters to update inventory ... no tracking whatsoever of what the tick represents or whether it is correct. I have never had a business NOT switch away from counters and tickers when this simple clarity is provided.
Wow, thanks for the in-depth information. That's very helpful to know.
Yet the failure you describe would affect logging the activity just as much as an incrementing number correct?
I agree that a more detailed record of what was done would be useful since counting how many times a script was performed only tells you that something was printed via the script, not what or when. I just don't follow the argument that this data will be any more vulnerable to loss due to a system failure than is the more detailed activity log.
"Yet the failure you describe would affect logging the activity just as much as an incrementing number correct?"
You still are missing the point. If the script failed in setting that the record printed today, you would KNOW it failed to print today because it adds the date. Incrementing a number by 1 does tell you anything of value. You cannot look back at that counter and know what it represents.
It isn't just during a system failure, Phil. What if the script broke and it didn't write for two weeks? How would you know unless there was a date attached to that counter which told you what those numbers mean? What if you wanted to know how many times it printed last year? A counter means nothing and should only be used by Developers when looping in scripts.
Well, anyway, most people grok the issue when explained.
It just seems to me that the failures you describe would nearly always result in failing to log a new activity record as well and so you would be left in the dark in either case.
To me, this is a really minor point so I'll drop it here.
Not a minor point at all, Phil. I used power loss as example. If you have a simple number field with 7 in it, you have no idea what it represents or whether it worked yesterday or hasn't worked for several days. By using a table with a date, you can see when it last updated; in fact, you can see every time it recorded.
I've seen inventory systems run on counters and they have no idea if they lost power whether it ran for the day's inventory. If they are using a record with a date, they will know if it didn't run or did. Counters provide no information and no history log of what the number represents and that is a VERY important difference.