>>In VFP a string lenght goes up to like x million... so, you probably won't hit it.
>>
>>BOb
>
>I think I have hit it - the application crapped out so badly that I couldn't even get any information as to the current size of the variable - I am going to implement a max size and then truncate according to some kind of FIFO rule, but I was hoping to see how far I could go. BTW, it is not yet confirmed that the size of the variable is the cause of the problem. Once I implement the max size I can repeat the test.

I've had similar trouble in FPD2.6. I was using m.vars for all the fields, including memos. Then I've added some extended editing capabilities (like pasting bits of text from another table's memo fields) to facilitate text entry. I've finally had some users with "out of memory" and similar messages (something regarding the string space, AFAI remember).

Then I've started playing with text entry, and measured the memory consumption. It appeared that for editing an 8K string it ate 30K or more - the more I edited, the quicker it ate, and finally exhausted the resources and broke. Then I've used a cursor with one record and just the memo fields instead, and the memory consumption didn't change a byte, no matter what games I played with text. I've concluded that editing a memo field is done directly within the buffer, and goes to disk if necessary, and doesn't happen in the string space at all. I've modified my screen generator to allow for memo fields as fields in this cursor (generated as well) and it works fine ever since. I've seen users actually typing long chapters within one memo field, and never had a problem. I write my help text in it, often pasting long excerpts from HTML versions of the same text, and never had any problem whatsoever.

I guess the internal logic of string and memo manipulation didn't actually change, so you may try to use a read/write cursor with a memo field, one blank record in it, and use that instead of the string variable.

HTH