According to the VFP 9 docs under "Visual FoxPro System
Capacities", the maximum string length is 16777184. What is the true
maximum, and where is it documented?

Adding characters ten at a time, I created a string of 40 million
characters.

If I start with one character and double, I get an error 1903
(String is too long to fit.) after 16777216 (2^24). (This is odd
since twice that is less than 40 million.)

If I start with one character and double up to 16777216, then add
1 MB at a time, I get an error 43 (There is not enough memory to
complete this operation.) after 383778816 (over 1/3 GB).

Since it is possible to create some very long strings and yet get
errors on shorter strings, what are the rules for l-o--n---g strings?

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Hi Gene,

In practice you can have longer strings, but the real maxmimum length depends on
the actual situation in working memory of your installation.

Regards
Bernhard Sander

Hi Gene,

with less than 16 MB strings you are on the sure side.
You can also create longer strings at once eg via
FILETOSTR() or SPACE().

I've read somewhere, that some operations can
fail on longer strings. Others are only limited by
the amount of RAM. But don't know which
operations. From what you say, the + operator
is even in both classes of operations: it works in
some cases and not in other cases.

Nevertheless I think the fast string functions like in-
string-search of VFP are optimized for table fields,
which can only be 254 characters long, despite of
memo fields.

There are different more complex algorithms, which
are faster for longer strings, eg the foxpro AT() can
be outperformed by Boyer-Moore algorithm for
string searches - at least I did so in some special
case, but that algorithm does some precalculation
which - although it's not that complex - can make it
slower for short strings.

I'd even cut longer strings into small portions
of say 8 to 16 KB and work on them in VFP
or do some special FLL/DLL for manipulation
of longer strings (I'm thinking about longer than
16MB here) or files. Mostly those longer
strings are files, aren't they?

Bye, Olaf.

"Olaf Doschke" <b2xhZi5kb3NjaGtlQHNldG1pY3MuZGU (AT) strconv (DOT) 14.de> wrote:

I think the limitation is on the string being added. VFP did not
add a 16 MB string to another 16 MB string, but did add a 1 MB to a
1/4+ GB one.

I was hoping that someone else did.

When I was testing length, I noted that adding did slow down as
the total string got longer. There was also one five-second break
shortly before VFP finally threw an error. I assume that memory was
being reshuffled.

Usually, yes. Very long strings can usually be broken up (by
rabid analysts -- us -- and so do not long survive as such.

In my case, they will be report pages. I had thought to put the
whole report in one page, so I was concerned about maximum length. I
decided to go to a string per page as with that, I can output to a
string array and have another array with the page orientation. See?
Another rabid analyst tears a long string to pieces.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Hi Gene,

16 MB for a pure text report is very much.
It would even be quite a lot, if it contained the text as graphics.
But if you think, that it is not enough for your report, you could save it in a
memo field of a dummy cursor. There the limit would be 2GB.
Simply use
REPLACE dummycursor.memofield WITH lcNextPartOfReport ADDITIVE

Or you write it into a file using low level file functions or TEXTMERGE

Regards
Bernhard Sander