Running into a problem with text.to.buf. So the buf field is string of 600 characters with max of 1000 lines. Now the issue is we have some lines that are 300 or more characters. So to convert to oracle I have to create blocks of 4000 characters. So I convert the lines into the buffer - add them all together in one huge text buffer and then write them out in chunks of 4000 characters. Works just fine - as long as the line is limited to 256 characters or less. So for the line in question I put three commands into the code - the first shows the total buffer len of 600, the second shows 256 every time. So does text to buf have a limit of 256? if yes then I have to figure something else out.


message(str$(len(buf(1,i))))
message(str$(len(strip$(buf(1,i)))))
message(buf(1,i))

Hi Mark

I tested this text.to.buf on my dev server and I put the string array having max characters as 300 and I was able to do so. It doesn't have any such limitations it seems.

I am on 10.4 with porting set 9.2a.1 (Unicode). Maybe it has something to do with the Porting set?

You aren't able to get more than 256 characters in the array element?

There is a note in programmers guide, on the function text.to.buf, not sure if this is relevant or not:
NOTE: When a database-text-field is entered as a long text-line
without any LF or CR, the data is stored in tttxt010 over more the one
entry, split in parts of 240 positions (tttxt010.seqe). In a script moving the
database-text-field into the function text.to.buf() and the reference buffer is
setup as text.buffer(240,40), all entries for the related database-text-field
should appear in the buffer, as long as the tttxt010.seqe field has the value
between 1 and 40. With the tttxt002.nlin value still at 1 for this text-entry, it
appears that only the first 240 positions of this text are transferred into the
text.buffer. Because of this, texts get lost in a script when applied.

Exactly what happens except it appears it makes it to 256 characters. If we get to reload text I might try a file method, but that is a lot slower. Thanks for answer.