>>>

>>>lcMemo={your memo field}
>>>lcMemo=strtran(lcMemo, chr(13)+chr(13), '  ')
>>>do while '  '$lcMemo
>>>    lcMemo=strtran(lcMemo, '  ', ' ')
>>>enddo

>>What about FoxTools Reduce? Are you still in FoxTools club? :)
>
>Depending on the version, FoxTools special string functions like Words() WordNum(), StrFilter() won't accept a string longer than 255 chars (up to 2.6a), or would chop the result if longer than 255 (all but the 7.0 functions which made it into the core language). In this case I didn't think reducing all CRs to spaces was an option, anyway - only double CRs. Therefore the above scenario.

I've played with reduce in VFP6.0, here is a simple test:

lcStr=repl("A  ",5000000)
lcStr=reduce(lcStr,"  ")
?len(lcStr)

Looks like it doesn't reduce correctly?

>
>The accidental typing of too many CRs into a memo field actually happened before even more, in DOS days, when Enter was the key to do the data entry. Now since Microsoft introduced data tabby, i.e. Tab became the key to leave the current field; however, in FPD2.x days you had decent memos, and you had the Enter key to move to the next field. It took users considerable time to understand that in a memo field (aka edit box) it has a different role, to start a paragraph, and it'd be the Tab or Ctrl-Tab which would take you to the next field. Of course, once they got out, they'd never go back and erase the extra lines, which were invisible anyway.

We have errors couple of times, then CR was written into memo field, and there was an attempt to &lcMemo. I haven't checked, if my colleague resolved this problem already.