Most recent edit on 2007-09-18 22:01:51 by InformaPlus [Code Formater 2]
Additions:
Update Running Total, exp=Value, How=Incr, Cnd:Status=Open
Update Running Total, exp=if(Status=Open,Value,0), How=Incr, Cnd:Yes
Deletions:
Update ‘Running Total’ exp=Value, How=Incr, Cnd:Status=’Open’
Update ‘Running Total’ exp=if(Status=’Open’,Value,0), How=Incr, Cnd:Yes
Edited on 2007-09-18 21:59:33 by InformaPlus [Code Formater]
Additions:
Leaving the ‘Condition’ parameter to ‘Yes’:
As we illustrated previously, the Incremental update mechanism is triggered through the ‘How’ parameter of the ‘Update’ operation. Another parameter of the ‘Update’ operation is the ‘Condition’ parameter. It is important to keep in mind that the engines Incremental embedded mechanism does all kind of automatic conditioning to perform the proper update for the right conditions in order to achieve the accumulation result. As such, it is recommended not to interfere with the mechanism by using the condition parameter on an Incremental Update operation. Doing so, will be a reason why the accumulation result may become erroneous at one point or another.
The alternative for performing ‘Conditional’ incremental update consist of using the IF() function directly in the expression of the ‘Update’ operation.
Let’s take an example of detail rows with both a ‘Value’ and a ‘Status’ fields. The ‘Status’ options being ‘Open’ and ‘Closed’. Let’s accumulate a running total of the values of all the ‘Open’ details. The ‘Closed’ details are not to be considered as part of the running total.
Update ‘Running Total’ exp=Value, How=Incr, Cnd:Status=’Open’
The right way to condition the accumulation of ‘Open’ details only is as follow:
Update ‘Running Total’ exp=if(Status=’Open’,Value,0), How=Incr, Cnd:Yes
It is important to understand that the Incremental Update mechanism is a processing option of the eDeveloper’s engine. It is not a generic “Referential Integrity” declaration that defines globally (once and for all) the “Running Total” nature of a numeric field. As such, it is the responsibility of the developer to maintain the integrity of a persistent (saved as a Real field) running Total at all points of modification of any associated details.
A typical example of such possible oversight is a purge process on some details table. The purge process being a batch process that is typically independent of the original online process, it may be forgotten at this point that deleting a detail row must also subtract the associated ‘Value’ of this row from the ‘Running Total’ to which it was accumulated. Forgetting to maintain the integrity at such point will lead to erroneous totals that may be quite difficult to explain after the fact. However, once it is not ignored, it is quite easy to perform with a ‘Normal’ Update operation in such case.
It is good practice to set the ‘Undo’ parameter of an ‘Incremental’ Update to ‘No’. This avoids the possibility that the user may ‘Cancel’ (<F2>) the result of the accumulation before it is saved to the database after some details have already been committed.
With SQL databases, it is possible to embed in a batch task the SQL command that can perform an accumulation on the server side and return the result when required to some virtual field of an eDeveloper online process. The ability of today’s relational databases to return such accumulation values over massive amount of details in a time that keeps the online process fully operational makes it less and less necessary to achieve Running totals persistence through Real field saved as such in the database. With DBMSs such as MSSQL, Oracle and others today, it is often advantageous to take advantage of such SQL command issuance to get the current values of a running total before it is processed further with some Incremental Update operation.
Deletions:
Leaving the ‘Condition’ parameter to ‘Yes’:
As we illustrated previously, the Incremental update mechanism is triggered through the ‘How’ parameter of the ‘Update’ operation. Another parameter of the ‘Update’ operation is the ‘Condition’ parameter. It is important to keep in mind that the engines Incremental embedded mechanism does all kind of automatic conditioning to perform the proper update for the right conditions in order to achieve the accumulation result. As such, it is recommended not to interfere with the mechanism by using the condition parameter on an Incremental Update operation. Doing so, will be a reason why the accumulation result may become erroneous at one point or another.
The alternative for performing ‘Conditional’ incremental update consist of using the IF() function directly in the expression of the ‘Update’ operation.
Let’s take an example of detail rows with both a ‘Value’ and a ‘Status’ fields. The ‘Status’ options being ‘Open’ and ‘Closed’. Let’s accumulate a running total of the values of all the ‘Open’ details. The ‘Closed’ details are not to be considered as part of the running total.
Update ‘Running Total’ exp=Value, How=Incr, Cnd:Status=’Open’
The right way to condition the accumulation of ‘Open’ details only is as follow:
Update ‘Running Total’ exp=if(Status=’Open’,Value,0), How=Incr, Cnd:Yes
It is important to understand that the Incremental Update mechanism is a processing option of the eDeveloper’s engine. It is not a generic “Referential Integrity” declaration that defines globally (once and for all) the “Running Total” nature of a numeric field. As such, it is the responsibility of the developer to maintain the integrity of a persistent (saved as a Real field) running Total at all points of modification of any associated details.
A typical example of such possible oversight is a purge process on some details table. The purge process being a batch process that is typically independent of the original online process, it may be forgotten at this point that deleting a detail row must also subtract the associated ‘Value’ of this row from the ‘Running Total’ to which it was accumulated. Forgetting to maintain the integrity at such point will lead to erroneous totals that may be quite difficult to explain after the fact. However, once it is not ignored, it is quite easy to perform with a ‘Normal’ Update operation in such case.
It is good practice to set the ‘Undo’ parameter of an ‘Incremental’ Update to ‘No’. This avoids the possibility that the user may ‘Cancel’ (<F2>) the result of the accumulation before it is saved to the database after some details have already been committed.
With SQL databases, it is possible to embed in a batch task the SQL command that can perform an accumulation on the server side and return the result when required to some virtual field of an eDeveloper online process. The ability of today’s relational databases to return such accumulation values over massive amount of details in a time that keeps the online process fully operational makes it less and less necessary to achieve Running totals persistence through Real field saved as such in the database. With DBMSs such as MSSQL, Oracle and others today, it is often advantageous to take advantage of such SQL command issuance to get the current values of a running total before it is processed further with some Incremental Update operation.
Edited on 2007-09-17 22:30:10 by InformaPlus [C1]
Additions:
The first comment to make about incremental update is that it does work and as such is truly a powerful feature to use when and where it applies. As you will read further here, there are things to consider and keep in mind when using Incremental logic. However, the way the engine supports the logic previously described is in itself very reliable and the way to proceed from a developer point of view is extremely RAD. You owe it to yourself to understand and master the incremental update feature of eDeveloper.
The following Incremental update operation will not work properly:
The right way to condition the accumulation of ‘Open’ details only is as follow:
Deletions:
The first comment to make about incremental update is that it does work and as such is truly a powerful feature to use when and where it applies. As you will read further here, there are things to consider and keep in mind when using activating Incremental logic. However, the way the engine supports the logic previously described is in itself very reliable and the way to proceed from a developer point of view is extremely RAD. You owe it to yourself to understand and master the incremental update feature of eDeveloper.
The following Incremental update operation will not work properly:
The right way to condition the accumulation of ‘Open’ details only is as follow:
Oldest known version of this page was edited on 2007-09-17 22:21:37 by InformaPlus [IU Further Considerations]
Page view:
Further considerations:
Incremental update does work:
The first comment to make about incremental update is that it does work and as such is truly a powerful feature to use when and where it applies. As you will read further here, there are things to consider and keep in mind when using activating Incremental logic. However, the way the engine supports the logic previously described is in itself very reliable and the way to proceed from a developer point of view is extremely RAD. You owe it to yourself to understand and master the incremental update feature of eDeveloper.
Leaving the ‘Condition’ parameter to ‘Yes’:
As we illustrated previously, the Incremental update mechanism is triggered through the ‘How’ parameter of the ‘Update’ operation. Another parameter of the ‘Update’ operation is the ‘Condition’ parameter. It is important to keep in mind that the engines Incremental embedded mechanism does all kind of automatic conditioning to perform the proper update for the right conditions in order to achieve the accumulation result. As such, it is recommended not to interfere with the mechanism by using the condition parameter on an Incremental Update operation. Doing so, will be a reason why the accumulation result may become erroneous at one point or another.
The alternative for performing ‘Conditional’ incremental update consist of using the IF() function directly in the expression of the ‘Update’ operation.
Example:
Let’s take an example of detail rows with both a ‘Value’ and a ‘Status’ fields. The ‘Status’ options being ‘Open’ and ‘Closed’. Let’s accumulate a running total of the values of all the ‘Open’ details. The ‘Closed’ details are not to be considered as part of the running total.
The following Incremental update operation will not work properly:
Update ‘Running Total’ exp=Value, How=Incr, Cnd:Status=’Open’
The right way to condition the accumulation of ‘Open’ details only is as follow:
Update ‘Running Total’ exp=if(Status=’Open’,Value,0), How=Incr, Cnd:Yes
Data integrity across processes:
It is important to understand that the Incremental Update mechanism is a processing option of the eDeveloper’s engine. It is not a generic “Referential Integrity” declaration that defines globally (once and for all) the “Running Total” nature of a numeric field. As such, it is the responsibility of the developer to maintain the integrity of a persistent (saved as a Real field) running Total at all points of modification of any associated details.
A typical example of such possible oversight is a purge process on some details table. The purge process being a batch process that is typically independent of the original online process, it may be forgotten at this point that deleting a detail row must also subtract the associated ‘Value’ of this row from the ‘Running Total’ to which it was accumulated. Forgetting to maintain the integrity at such point will lead to erroneous totals that may be quite difficult to explain after the fact. However, once it is not ignored, it is quite easy to perform with a ‘Normal’ Update operation in such case.
Undo = No:
It is good practice to set the ‘Undo’ parameter of an ‘Incremental’ Update to ‘No’. This avoids the possibility that the user may ‘Cancel’ (<F2>) the result of the accumulation before it is saved to the database after some details have already been committed.
When working with SQL databases:
With SQL databases, it is possible to embed in a batch task the SQL command that can perform an accumulation on the server side and return the result when required to some virtual field of an eDeveloper online process. The ability of today’s relational databases to return such accumulation values over massive amount of details in a time that keeps the online process fully operational makes it less and less necessary to achieve Running totals persistence through Real field saved as such in the database. With DBMSs such as MSSQL, Oracle and others today, it is often advantageous to take advantage of such SQL command issuance to get the current values of a running total before it is processed further with some Incremental Update operation.
Back To:
Incremental Update
The original version of this page was provided by: InformaPlus
