Hi Thomas,

I wrote my message with another meaning than starting a discussion. I think we all know pretty well what we are talking about.

Mohammed obviously is in a learning phase, and even though you can do most thing in VFP in a lot of ways, I think we only confuse him with too many different solutions. I try to always give him the easiest and/or quickest solutions, I think that is best for him.

>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