>>>Try this (modified from Cetin code) for testing if the replaced string is being split during FREADs:
>>>
>>>>
>>>#DEFINE MAXBUFFER 65536
>>>lhIn = FOPEN(lcFileIn)
>>>lhOut = FCREATE(lcFileOut)
>>>DO WHILE NOT FEOF(m.lhIn )
>>> lcBuffer = FREAD(m.lhIn, MAXBUFFER)
>>> DO CASE
>>> CASE RIGHT(lcBuffer,3) = 'AD0'
>>> FSEEK(m.lhIn, -3, 1)
>>> lcBuffer = LEFT(lcBuffer,LEN(lcBuffer)-3)
>>> CASE RIGHT(lcBuffer,2) = 'AD'
>>> FSEEK(m.lhIn, -2, 1)
>>> lcBuffer = LEFT(lcBuffer,LEN(lcBuffer)-2)
>>> CASE RIGHT(lcBuffer,1) = 'A'
>>> FSEEK(m.lhIn, -1, 1)
>>> lcBuffer = LEFT(lcBuffer,LEN(lcBuffer)-1)
>>> ENDCASE
>>> FWRITE(m.lhOut,STRTRAN(lcBuffer,'AD00','BR77'),MAXBUFFER)
>>>ENDDO
>>>FCLOSE(m.lhIn)
>>>FCLOSE(m.lhOut)
>>
>>this is incorrect.
>>you cannot mix a right find/replace with a left find/replace
>
>I am not sure what you mean cannot mix a right find/replace with a left find replace. The above code looks at >the last 3 bytes to determine if they can possibly be part of the search string. If there is a possiblity, >then >the position in the file is moved by the number of possible matching bytes (FSEEK) and the possible >matching >bytes is removed from the read buffer before any string replacement is made.
>
>This is the issue.
>example:
>
>find "AD0A" replace with "BR77"
>lcBuffer = ".....AD0A"
>the line
> CASE RIGHT(lcBuffer,1) = 'A'
>find the A, remove it and you lose a raplacement!
>
>> When the next FREAD occurs, it now from the adjusted position in the file which will now read back in the >possible >matching bytes at the start of the new buffer. This is repeated until the entire buffer is read in >and the string >translated.

I see your point -- the code above was for the test strings given; not for all possible conversions. If you want to have any possible conversions of strings, then more checking of the end possible overlap must be performed. This would have to be accomplished in the CASE statement at the point of possible overlap. You would need to test for the various interations of the string which could be exhaustive. Therefore, if you want to allow all possible string conversions without restriction, then I would fall back to an FLL as well and write it in C as Cetin proposed.

It is easy to code a solution and walk on water when both are frozen...