Page 1 of 1

Is there a limitation for the size of a string?

Posted: Thu Jun 08, 2017 2:05 pm
by greg falda
Dear All

I'm planning to pass queries to SQL databases, where the queries can be potentially really long, like

Code: Select all

INSERT INTO ... VALUES ...;
where the VALUES may contain multiple rows of multiple records.

Hence my question:

Is there a limitation for the size (length) of a string in LiveCode?

Thanks in advance for your help

best
greg falda

Re: Is there a limitation for the size of a string?

Posted: Thu Jun 08, 2017 3:52 pm
by dunbarx
I think a string cannot go past the 32 bit limit, at least in 32 bit applications.

But this seems to fall short of that:

Code: Select all

on mouseUp
   put "1234567890" into temp
   repeat 26
      put temp after temp
   end repeat
   answer the length of temp --about 670,000,000 bytes
end mouseUp
If you run 27 times, LC aborts, though that length should only be about 1.3 GB. Other unknown overhead?

Craig Newman

Re: Is there a limitation for the size of a string?

Posted: Thu Jun 08, 2017 4:13 pm
by Klaus
Hi Greg,

open the "User Guide" (LC Menu -> Help) and see page 63, or search for "LiveCode Memory Limits".


Best

Klaus

Re: Is there a limitation for the size of a string?

Posted: Thu Jun 08, 2017 5:11 pm
by FourthWorld
dunbarx wrote:I think a string cannot go past the 32 bit limit, at least in 32 bit applications.

But this seems to fall short of that:

Code: Select all

on mouseUp
   put "1234567890" into temp
   repeat 26
      put temp after temp
   end repeat
   answer the length of temp --about 670,000,000 bytes
end mouseUp
If you run 27 times, LC aborts, though that length should only be about 1.3 GB. Other unknown overhead?
The 4GB of space addressable with 32-bit processes includes everything in the process. Beyond that, there are often limits with OS APIs on malloc size for certain operations. It may be that the limit you've found may be related to the latter, or a mix of both.

What are you building that needs a single string > 1.3 B? I'll bet there's a more RAM-friendly way to solve that problem.