Hi Tore,

>the BIG problem with your code is that it is not rushmore optimizable.

I fully realize that. That is why
>>if there is no index on char8 to help
>>each replace with rushmore.
was written before giving that possibility <bg>.

Since index/no index was not specified and is discussible
depending on the use of the table and the distribution of entries
in the field I just gave another option, expecially for the case
"no index". Even if an index exists, the speed of the update/replace
probably depends on the number of records not changed at all:
if there are many, the indexed solution is probably faster,
if there are few to none the non-indexed or unoptimized solution
will be faster, since the table can be processed in natural order
only once.

>My UPDATE suggestion is by far the simplest,
"by far" ? from my point of view, more like "variations of a theme" <g>.

>and probably also the quickest.
Perhaps - depends on the data.

>You are wrong when you say that the whole table has to be scanned every time, unless there is no index tag on CHAR8.
Here I can't follow your reasoning: please explain a bit...

>WITH this index tag, only the index has to be scanned, and since the index probably is in RAM, this >scan will be lightening fast.
Agreed and mentioned by me. Where are we disagreeing here ?

>Another problem is that REPLACE ALL will lock the header of the table, meaning that all other users only has read access to the file while the REPLACE command is executed. This is not, as far as I know, the case with UPDATE.

Yupp, Replace will lock the header while update uses record locking.
Should "update" be preferred ? IMHO also dependant on the situation <g>.
Replace with the header lock will be faster, and I was *guessing* such operations
(if multi-user is the case here...) would be done in a "table update" scenario.
If single use is the case, for nearly identical perf you need to
flock, update and unlock. No data was given ;-)

>Just because you can do something in one line with a lot of iif's,
>does not necessarily mean that you should do it that way.
Agreed - but I still guess the table lookup is the
most generic and flexible <g>.

Which "pure code" version is better ?
Even here "my" standards would depend on the situation. If the "iif"
is always the same and readable on half a screen page, this is probably
the best way for me to quickly read/change the code.

No redundant coding of the target table/field name:
it might change <bg>.

my 0.02 EUR

thomas