I have created a single report schedule which is disabled. I have then created an Event Based Schedule triggered on "Record Exisisting". When a record exists, the report is populated and it fires off an email with the report attached. This works fine, but it then fails to stop sending to report. It sends one report every time the polling interval refreshes.
I checked on HELP and it says to make a custom action to edit the record, however, I do not want to, nor should be able to edit the record in this way.
Is there anyway to simply run the initial email without it repeating, and without the need to change a record in my database.
As you have discovered, CRD does not keep a local record of which database records it has acted on. CRD relies on you creating the flag yourself.
This is for the following reasons:
1. If the file we keep our records in becomes corrupt and has to be deleted, then every record that has ever satisfied the condition will be acted on again. This is one of the biggest failings of other business automation software. It is also one of the biggest nightmares when thousands of emails etc. are sent to customers for records and events which happened months or years ago. Anyone who has been in this situation beofre knows what it feels like to be in the firing line under these circumstances and, in our surveys, has preferred the much safer and definite method we currently use.
2. If the CRD machine crashed (hardware) and CRD had to be installed on another server or PC, then the above situation would also happen as the local file would have "crashed" with the hardware.
3. The network traffic and other resources on the database server required to compare local and server databases would slow down the performance of your database. This would be noticeable especially to fat-client users of database entry software. For this reason, regular business automation software has the reputation of "grinding the database down" whilst its polling. To alleveate this, polling intervals are set in tens of minutes for other software instead of seconds as with CRD.
If you absolutely do not want to write a "done" flag to your actual database, then I would suggest that you replicate the information to a new table using your database's replication capabilities, or triggers, then get CRD to act on, and place markers, in the new replicated table.
At the end of the day, CRD will only write to your database what it is told to write. It performs no other functionality other than that, and you can see and test the full sql statement it produces to ensure that you are comfortable with what it is doing.
I have added the ability to store local flags on the enhancement list, but this will probably not come in till we introduce MSPE and give CRD the ability to write its database ebtries etc. to a proper database e.g. on your SQL or oracle database server through an ODBC. That way, if the local CRD were to go down as described above, it wouldn't matter as the records are stored in a separate location anyway.
We expect to have the above technology in place by the end of this year, so keep your eyes peeled on the history page.
