>>>I was getting an error and I sensed that the reason was the extra parameter I added. You confirmed it.
>
>I hesitate to mention performance after some recent threads(!) but passing lots of/large parameters definitely carries a performance hit. The other option is PRIVATE variables or parameter objects in the calling code: you can have as many as you need that are visible to called functions without the performance impact.

There was a situation where I had to have a few private variables (and write WARNING comments all around) because of the code in bizobject class, which would do the tableupdate() somewhere deep where these would then be invisible - and they were ?parameters in the SQL statement.

It didn't occur to me to check the speed penalty for parameters, because if anything was slow, it was usually the denormalized cursors brought from SQL, that's slow. Which is why I'd usually get a decent speed gain by not joining them SQL side, but rather bringing each of them in one command (and renaming aliases accordingly), then joining them in Fox. The bulk that went down the wire was significantly reduced - the nearly cartesian product size vs sum of its factors - and that was all the speed gain I needed. Squeezing extra permille by juggling parameters would be an exercise in reduced gains.