>>

lcPattern=Stuff(tcDBFName,lnPos+2, 2, '???')

>>A single function should be faster than two functions plus two string concatenateions. Besides, I always thought that all the string chopping functions (left, right, substr()) are internally done as Stuff() with special parameters.
>
>Yes, you're right.
>
>This is the test:
>

>local lcPatern, lnSec, lnPos, tcDBFName, i
>
>tcDBFName=replicate("bkl",30)
>lnPos=20
>lnSec=seconds()
>for i=1 to 100000
>    lcPattern=left(tcDBFName,lnPos+1)+'???'+substr(tcDBFName,lnPos+4)
>endfor
>?seconds()-lnSec
>lnSec=seconds()
>for i=1 to 100000
>   lcPattern=Stuff(tcDBFName,lnPos+2, 2, '???')
>   endfor
>?seconds()-lnSec

>
>BTW, I can not use chrtran for chrtran(lcString,["],"") because of the bug in chrtran. David Frankenbah mentioned it, see the problem in WiKi.

Good one - didn't know this before. I rarely used it for anything big, so this never occurred to me.

BTW, my usual way of doing string grinding on big text files is (in meta-code)

  ih=fopen([filename], read_only)
  oh=fcreate([new filename])
  do while not feof(ih)
     cBuff=fread(ih, 8192)   && use any suitable round number
     cOutBuff=CrunchMunch(cBuff)
     =fwrite(oh, cOutBuff)
  enddo
  CloseEmAll

Using a 'suitable round number' comes from my belief that the least overhead will be induced if we respect natural boundaries, i.e. blocksizes etc. You may work in 32K or 64K chunks if you like - run a few tests and see.

>P.S. You're older, than I thought :)

Don't be fooled by the facts :)