Hi Stephan, you found a very specific case, which is interesting nevertheless.
Your update-script contained Data Conversion to batch-wise convert data following a component change.
The data conversion was setting a value for a new Cached Function. In this case, it was expectedtransactionline.payment_method.
This is a Cached Function that non-normalized data for performance reasons. The Payment Method is already set at the Expected Transaction; this cached function stores the value at each line.
In small database tables, the Cached Fields Checker fixes these functions automatically after installations.
But when you perform an update on a large (production) application, the Cached Fields fixer is not fase enough for very high volumes. In these cases, it makes sense to pre-fill the Cached fields in the update-script.
Because some customers have millions of records here, a simple UPDATE statement would also be too long. Therefore, a specific custom piece of script was created to process it in batched of 10000 rows.
To keep track of this, variables @Rows where declared in the update-script, to support batch-wise processing.
However, in your large update, you happened to have to tables with such a procedure, so the name @Rows was double.
The solution was to rename the @Rows and @BatchSize SQL variables to something really unique (here: @Rows_PI12345 with the PI-number).
Pro tip / best practice: When writing data conversion in these cases, make sure the helper variables are unique.