In four locations the use of bindVars was not correctly implemented. In each case the sql statement had a variable formatted like ':var:' but in the substitution performed by bindVars the variable was identified as only ':var' this causes an extra : to remain behind in the sql.
This method of substitution has been chosen to prevent incorrect substitution from occurring because of incorrect sequencing of the bindVars functions when more than one variable begins with the same text as one that is fully defined by that beginning text. Ie. :value substituted into :value_me will cause an issue if :value_me isn't listed before :value in the bindVars sequencing. Generally speaking ZC table fields are unique throughout at least on non-linking fields and therefore the occurrence of something like this is low, but it does appear to be a safe programming standard to minimize the occurrence of "unknown/unexpected" results.
In four locations the use of bindVars was not correctly implemented. In each case the sql statement had a variable formatted like ':var:' but in the substitution performed by bindVars the variable was identified as only ':var' this causes an extra : to remain behind in the sql.
This method of substitution has been chosen to prevent incorrect substitution from occurring because of incorrect sequencing of the bindVars functions when more than one variable begins with the same text as one that is fully defined by that beginning text. Ie. :value substituted into :value_me will cause an issue if :value_me isn't listed before :value in the bindVars sequencing. Generally speaking ZC table fields are unique throughout at least on non-linking fields and therefore the occurrence of something like this is low, but it does appear to be a safe programming standard to minimize the occurrence of "unknown/unexpected" results.