limitation on string of 255 bytes???

hi
i can't create a string of more than 255 bytes....
what is happening...?
this don't occurred before...

bye, thanks
ks

keyser
Mon Jul 07 10:59:19 CDT 2008

mmhmmhmh...
only on the command window....


"keyser soze" <bajopalabra@hotmail.com> escribió en el mensaje
news:%23TMZXmE4IHA.4720@TK2MSFTNGP03.phx.gbl...
| hi
| i can't create a string of more than 255 bytes....
| what is happening...?
| this don't occurred before...
|
| bye, thanks
| ks

Fred
Mon Jul 07 11:05:08 CDT 2008

You can't create a constant string value of more than 255 characters. A
string can contain up to 16 million characters.

If your string is too large, then break it up into pieces:


MyLongString = "This is a potion of a very, "+;
"very, very, very, long string "+;
"yada, yada, yada....."+;
" with each part between the quotes"+;
" less than 255 characters."

It's always been this way.

--
Fred
Microsoft Visual FoxPro MVP


"keyser soze" <bajopalabra@hotmail.com> wrote in message
news:%23TMZXmE4IHA.4720@TK2MSFTNGP03.phx.gbl...
> hi
> i can't create a string of more than 255 bytes....
> what is happening...?
> this don't occurred before...
>
> bye, thanks
> ks

Dan
Mon Jul 07 14:17:10 CDT 2008

Or you could use TEXT TO MEMVAR. <g>

Dan

Fred Taylor wrote:
> You can't create a constant string value of more than 255 characters.
> A string can contain up to 16 million characters.
>
> If your string is too large, then break it up into pieces:
>
>
> MyLongString = "This is a potion of a very, "+;
> "very, very, very, long string "+;
> "yada, yada, yada....."+;
> " with each part between the quotes"+;
> " less than 255 characters."
>
> It's always been this way.
>
>
> "keyser soze" <bajopalabra@hotmail.com> wrote in message
> news:%23TMZXmE4IHA.4720@TK2MSFTNGP03.phx.gbl...
>> hi
>> i can't create a string of more than 255 bytes....
>> what is happening...?
>> this don't occurred before...
>>
>> bye, thanks
>> ks

keyser
Mon Jul 07 15:20:12 CDT 2008

yes,
that's the way


"keyser soze" <bajopalabra@hotmail.com> escribió en el mensaje
news:%23TMZXmE4IHA.4720@TK2MSFTNGP03.phx.gbl...
| hi
| i can't create a string of more than 255 bytes....
| what is happening...?
| this don't occurred before...
|
| bye, thanks
| ks

Lew
Wed Jul 09 18:18:58 CDT 2008

Wasn't there a time when it was 1k chars?

"Fred Taylor" <ftaylor@mvps.org!REMOVE> wrote in message
news:eL6dZrE4IHA.1192@TK2MSFTNGP05.phx.gbl...
> You can't create a constant string value of more than 255 characters. A
> string can contain up to 16 million characters.
>
> If your string is too large, then break it up into pieces:
>
>
> MyLongString = "This is a potion of a very, "+;
> "very, very, very, long string "+;
> "yada, yada, yada....."+;
> " with each part between the quotes"+;
> " less than 255 characters."
>
> It's always been this way.
>
> --
> Fred
> Microsoft Visual FoxPro MVP
>
>
> "keyser soze" <bajopalabra@hotmail.com> wrote in message
> news:%23TMZXmE4IHA.4720@TK2MSFTNGP03.phx.gbl...
>> hi
>> i can't create a string of more than 255 bytes....
>> what is happening...?
>> this don't occurred before...
>>
>> bye, thanks
>> ks
>
>

Fred
Wed Jul 09 20:01:36 CDT 2008

As which, the constant size or the maximum string size? Maybe in dBase][ it
was 1K for maximum size, but constants have always been 255 from what I can
recall.

--
Fred
Microsoft Visual FoxPro MVP


"Lew" <lew@fastmail.fm> wrote in message
news:eXfVsoh4IHA.3480@TK2MSFTNGP03.phx.gbl...
> Wasn't there a time when it was 1k chars?
>
> "Fred Taylor" <ftaylor@mvps.org!REMOVE> wrote in message
> news:eL6dZrE4IHA.1192@TK2MSFTNGP05.phx.gbl...
>> You can't create a constant string value of more than 255 characters. A
>> string can contain up to 16 million characters.
>>
>> If your string is too large, then break it up into pieces:
>>
>>
>> MyLongString = "This is a potion of a very, "+;
>> "very, very, very, long string "+;
>> "yada, yada, yada....."+;
>> " with each part between the quotes"+;
>> " less than 255 characters."
>>
>> It's always been this way.
>>
>> --
>> Fred
>> Microsoft Visual FoxPro MVP
>>
>>
>> "keyser soze" <bajopalabra@hotmail.com> wrote in message
>> news:%23TMZXmE4IHA.4720@TK2MSFTNGP03.phx.gbl...
>>> hi
>>> i can't create a string of more than 255 bytes....
>>> what is happening...?
>>> this don't occurred before...
>>>
>>> bye, thanks
>>> ks
>>
>>
>
>

Gene
Wed Jul 09 21:00:36 CDT 2008

"Fred Taylor" <ftaylor@mvps.org!REMOVE> wrote:

>As which, the constant size or the maximum string size? Maybe in dBase][ it
>was 1K for maximum size, but constants have always been 255 from what I can
>recall.

Oddly, columns are limited to c(254). IIRC, this dates from
dBASE II. I do not remember if strings were similarly limited.

254 is weird.

Sincerely,

Gene Wirchenko

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

Fred
Wed Jul 09 23:40:59 CDT 2008

Not really all that strange. To keep the field size total to 256, that
leaves 1 byte for the delete mark, 1 byte for the field width size, and 254
for the string.

--
Fred
Microsoft Visual FoxPro MVP


"Gene Wirchenko" <genew@ocis.net> wrote in message
news:32ra74pjs6rklnqfd4d6nhqr01n5g9l86c@4ax.com...
> "Fred Taylor" <ftaylor@mvps.org!REMOVE> wrote:
>
>>As which, the constant size or the maximum string size? Maybe in
>>dBase][ it
>>was 1K for maximum size, but constants have always been 255 from what I
>>can
>>recall.
>
> Oddly, columns are limited to c(254). IIRC, this dates from
> dBASE II. I do not remember if strings were similarly limited.
>
> 254 is weird.
>
> Sincerely,
>
> Gene Wirchenko
>
> Computerese Irregular Verb Conjugation:
> I have preferences.
> You have biases.
> He/She has prejudices.

Bernhard
Thu Jul 10 03:59:38 CDT 2008

Hi Fred,

> Not really all that strange. To keep the field size total to 256, that
> leaves 1 byte for the delete mark,
Why should there be a delete mark at every character field?

Regards
Bernhard Sander

Dan
Thu Jul 10 10:50:07 CDT 2008

Bernhard Sander wrote:
> Hi Fred,
>
>> Not really all that strange. To keep the field size total to 256,
>> that leaves 1 byte for the delete mark,
> Why should there be a delete mark at every character field?

Or the field width? Isn't that stored in the header?

(Although we DO lose a byte on each field if it accepts NULL.)

Dan

Fred
Thu Jul 10 11:07:04 CDT 2008

Thanks for the correction Dan. It's a NULL position, not a delete marker.

--
Fred
Microsoft Visual FoxPro MVP


"Dan Freeman" <spam@microsoft.com> wrote in message
news:emfMiSq4IHA.4988@TK2MSFTNGP04.phx.gbl...
> Bernhard Sander wrote:
>> Hi Fred,
>>
>>> Not really all that strange. To keep the field size total to 256,
>>> that leaves 1 byte for the delete mark,
>> Why should there be a delete mark at every character field?
>
> Or the field width? Isn't that stored in the header?
>
> (Although we DO lose a byte on each field if it accepts NULL.)
>
> Dan
>

Dan
Thu Jul 10 11:23:50 CDT 2008

Had a feeling that's what you were thinking. ;-)

Dan

Fred Taylor wrote:
> Thanks for the correction Dan. It's a NULL position, not a delete
> marker.
>
> "Dan Freeman" <spam@microsoft.com> wrote in message
> news:emfMiSq4IHA.4988@TK2MSFTNGP04.phx.gbl...
>> Bernhard Sander wrote:
>>> Hi Fred,
>>>
>>>> Not really all that strange. To keep the field size total to 256,
>>>> that leaves 1 byte for the delete mark,
>>> Why should there be a delete mark at every character field?
>>
>> Or the field width? Isn't that stored in the header?
>>
>> (Although we DO lose a byte on each field if it accepts NULL.)
>>
>> Dan

Bernhard
Thu Jul 10 12:06:09 CDT 2008

Hi Fred,

> Thanks for the correction Dan. It's a NULL position, not a delete marker.
As Gene pointe out, the lenght of 254 was already there in dBase II, at that
time NULL was not in dBase.
If I understand the actual docs correctly, then the NULL value is stored in one
bit of an extra invisible column, one bit of this field is set, if the
corresponding data field is set to NULL.

But we can talk a lot about this strange length for character fields...

Regards, enjoy the summer, if you live on the northern half of this planet...
Bernhard Sander

Lew
Thu Jul 10 17:28:01 CDT 2008

It's probably a pascal string type (which you can use in c). The first byte
tells the string length (leaving a max of 254 for the rest of the string).
This is unlike c type strings that are of indefinite length, but terminate in
chr(0).

"Gene Wirchenko" wrote:

> "Fred Taylor" <ftaylor@mvps.org!REMOVE> wrote:
>
> >As which, the constant size or the maximum string size? Maybe in dBase][ it
> >was 1K for maximum size, but constants have always been 255 from what I can
> >recall.
>
> Oddly, columns are limited to c(254). IIRC, this dates from
> dBASE II. I do not remember if strings were similarly limited.
>
> 254 is weird.
>
> Sincerely,
>
> Gene Wirchenko
>
> Computerese Irregular Verb Conjugation:
> I have preferences.
> You have biases.
> He/She has prejudices.
>

Gene
Thu Jul 10 18:36:23 CDT 2008

Lew <Lew@discussions.microsoft.com> wrote:

>It's probably a pascal string type (which you can use in c). The first byte
>tells the string length (leaving a max of 254 for the rest of the string).

Why would the length be part of the string? That is like 3122
being the three-digit number 122.

>This is unlike c type strings that are of indefinite length, but terminate in
>chr(0).

[snip]

Sincerely,

Gene Wirchenko

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

Lew
Thu Jul 10 19:07:17 CDT 2008

When you request bytes from the heap manager in these languages all you get
is the starting address of the bytes and the guarantee that the remaining
bytes are not allocated to any other address, however, the heap manager does
not track the actual number of bytes you subsequently use. Your program or
code needs to provide some method of determining this. A library of pascal
string type routines will use the first byte to track the length, std c
routines just retrieve everything from the starting address until they
encounter chr(0). For instance, a pascal string based len() function need
only return the ascii value of the first byte, whereas the c based
equivalent will have to actually count every non-0 byte to find the length.

"Gene Wirchenko" <genew@ocis.net> wrote in message
news:547d74l0gktmengjep3bc0nrm3g7o7effe@4ax.com...
> Lew <Lew@discussions.microsoft.com> wrote:
>
>>It's probably a pascal string type (which you can use in c). The first
>>byte
>>tells the string length (leaving a max of 254 for the rest of the string).
>
> Why would the length be part of the string? That is like 3122
> being the three-digit number 122.
>
>>This is unlike c type strings that are of indefinite length, but terminate
>>in
>>chr(0).
>
> [snip]
>
> Sincerely,
>
> Gene Wirchenko
>
> Computerese Irregular Verb Conjugation:
> I have preferences.
> You have biases.
> He/She has prejudices.

Gene
Thu Jul 10 19:40:38 CDT 2008

"Lew" <lew@fastmail.fm> wrote:

>When you request bytes from the heap manager in these languages all you get
>is the starting address of the bytes and the guarantee that the remaining
>bytes are not allocated to any other address, however, the heap manager does
>not track the actual number of bytes you subsequently use. Your program or

It does track how many bytes were allocated.

>code needs to provide some method of determining this. A library of pascal
>string type routines will use the first byte to track the length, std c
>routines just retrieve everything from the starting address until they
>encounter chr(0). For instance, a pascal string based len() function need
>only return the ascii value of the first byte, whereas the c based
>equivalent will have to actually count every non-0 byte to find the length.

I know that, but why count the length byte as part of the string?

[snip]

Sincerely,

Gene Wirchenko

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

Fred
Thu Jul 10 19:54:04 CDT 2008

"Gene Wirchenko" <genew@ocis.net> wrote in message
news:isad74dejfui2jr43mct1aaql0qc6gvq76@4ax.com...
> "Lew" <lew@fastmail.fm> wrote:
>
>>When you request bytes from the heap manager in these languages all you
>>get
>>is the starting address of the bytes and the guarantee that the remaining
>>bytes are not allocated to any other address, however, the heap manager
>>does
>>not track the actual number of bytes you subsequently use. Your program or
>
> It does track how many bytes were allocated.
>
>>code needs to provide some method of determining this. A library of pascal
>>string type routines will use the first byte to track the length, std c
>>routines just retrieve everything from the starting address until they
>>encounter chr(0). For instance, a pascal string based len() function need
>>only return the ascii value of the first byte, whereas the c based
>>equivalent will have to actually count every non-0 byte to find the
>>length.
>
> I know that, but why count the length byte as part of the string?
>
> [snip]
>

Because it is part of the string. You wouldn't want the length value to
separated from the data it's reporting the length of.

--
Fred
Microsoft Visual FoxPro MVP

Bernhard
Fri Jul 11 04:38:01 CDT 2008

Hi Lew,

> It's probably a pascal string type (which you can use in c). The first byte
> tells the string length (leaving a max of 254 for the rest of the string).
> This is unlike c type strings that are of indefinite length, but terminate in
> chr(0).
>
> "Gene Wirchenko" wrote:
>
>> "Fred Taylor" <ftaylor@mvps.org!REMOVE> wrote:
>>
>>> As which, the constant size or the maximum string size? Maybe in dBase][ it
>>> was 1K for maximum size, but constants have always been 255 from what I can
>>> recall.
>> Oddly, columns are limited to c(254). IIRC, this dates from
>> dBASE II. I do not remember if strings were similarly limited.
>>
>> 254 is weird.
>>
A dBase character field always has a fixed length, also called field width, no
matter how many bytes you store in it. The field is always filled up with
blanks. The field width is stored in the table header.

It is a little different with varchar fields of foxpro. There the actual length
is stored in the last byte of the field, but only if it is not completely
filled. There is a special bit in an extra, invisible system column which
indicates, whether the varchar field is completely filled or not.

But in dBase II there weren't varchar fields

Regards
Bernhard Sander

Gene
Fri Jul 11 17:06:20 CDT 2008

"Fred Taylor" <ftaylor@mvps.org!REMOVE> wrote:

[snip]

>Because it is part of the string. You wouldn't want the length value to
>separated from the data it's reporting the length of.

But it is not. If I am storing a surname is a string, say
"Wirchenko", the first character of the string is W, not the length of
the string.

I do not care if it is separate, just that it is accessible.

Sincerely,

Gene Wirchenko

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

Fred
Fri Jul 11 17:34:55 CDT 2008

It's only part of the table field. I do not know what the in-memory format
of a string is, but in any case, you don't have to deal with it in FoxPro,
as it handles it correctly. What the structure/formatting of the field in
the table is also not a concern, except for the historically inherited
limitation of 254 for a table character type field.

--
Fred
Microsoft Visual FoxPro MVP


"Gene Wirchenko" <genew@ocis.net> wrote in message
news:g8mf74t65vs0mqfj3rmu6orspoqm7ab05b@4ax.com...
> "Fred Taylor" <ftaylor@mvps.org!REMOVE> wrote:
>
> [snip]
>
>>Because it is part of the string. You wouldn't want the length value to
>>separated from the data it's reporting the length of.
>
> But it is not. If I am storing a surname is a string, say
> "Wirchenko", the first character of the string is W, not the length of
> the string.
>
> I do not care if it is separate, just that it is accessible.
>
> Sincerely,
>
> Gene Wirchenko
>
> Computerese Irregular Verb Conjugation:
> I have preferences.
> You have biases.
> He/She has prejudices.

Lew
Fri Jul 11 18:18:11 CDT 2008

I thought this discussion was about string lengths not field widths. Was I
wrong?
"Bernhard Sander" <fuchs@no.spam> wrote in message
news:eP4oQnz4IHA.5012@TK2MSFTNGP02.phx.gbl...
> Hi Lew,
>
>> It's probably a pascal string type (which you can use in c). The first
>> byte tells the string length (leaving a max of 254 for the rest of the
>> string). This is unlike c type strings that are of indefinite length, but
>> terminate in chr(0).
> >
>> "Gene Wirchenko" wrote:
>>
>>> "Fred Taylor" <ftaylor@mvps.org!REMOVE> wrote:
>>>
>>>> As which, the constant size or the maximum string size? Maybe in
>>>> dBase][ it was 1K for maximum size, but constants have always been 255
>>>> from what I can recall.
>>> Oddly, columns are limited to c(254). IIRC, this dates from
>>> dBASE II. I do not remember if strings were similarly limited.
>>>
>>> 254 is weird.
>>>
> A dBase character field always has a fixed length, also called field
> width, no matter how many bytes you store in it. The field is always
> filled up with blanks. The field width is stored in the table header.
>
> It is a little different with varchar fields of foxpro. There the actual
> length is stored in the last byte of the field, but only if it is not
> completely filled. There is a special bit in an extra, invisible system
> column which indicates, whether the varchar field is completely filled or
> not.
>
> But in dBase II there weren't varchar fields
>
> Regards
> Bernhard Sander

Fred
Fri Jul 11 18:39:21 CDT 2008

Character field limits are 254, string constants are 255, and string
variables are 16,777,184 (VFP9). The discussion has been about all three at
one point or another.

--
Fred
Microsoft Visual FoxPro MVP


"Lew" <lew@fastmail.fm> wrote in message
news:%23D3Rmx64IHA.3480@TK2MSFTNGP03.phx.gbl...
>I thought this discussion was about string lengths not field widths. Was I
>wrong?
> "Bernhard Sander" <fuchs@no.spam> wrote in message
> news:eP4oQnz4IHA.5012@TK2MSFTNGP02.phx.gbl...
>> Hi Lew,
>>
>>> It's probably a pascal string type (which you can use in c). The first
>>> byte tells the string length (leaving a max of 254 for the rest of the
>>> string). This is unlike c type strings that are of indefinite length,
>>> but terminate in chr(0).
>> >
>>> "Gene Wirchenko" wrote:
>>>
>>>> "Fred Taylor" <ftaylor@mvps.org!REMOVE> wrote:
>>>>
>>>>> As which, the constant size or the maximum string size? Maybe in
>>>>> dBase][ it was 1K for maximum size, but constants have always been 255
>>>>> from what I can recall.
>>>> Oddly, columns are limited to c(254). IIRC, this dates from
>>>> dBASE II. I do not remember if strings were similarly limited.
>>>>
>>>> 254 is weird.
>>>>
>> A dBase character field always has a fixed length, also called field
>> width, no matter how many bytes you store in it. The field is always
>> filled up with blanks. The field width is stored in the table header.
>>
>> It is a little different with varchar fields of foxpro. There the actual
>> length is stored in the last byte of the field, but only if it is not
>> completely filled. There is a special bit in an extra, invisible system
>> column which indicates, whether the varchar field is completely filled or
>> not.
>>
>> But in dBase II there weren't varchar fields
>>
>> Regards
>> Bernhard Sander
>
>