Field storage data limit for indexed field in Progress 9.1D

[Pavan Yadav]

Hi All,

I am not very much sure about the limit a character type field in Progress can store in. But, I read somewhere that there is limit for storage in indexed field i.e. 188 chars.
But, my concern is that this 188 is length or some sort of storage area. Because with normal english character it's 188 char, but when I tried to store russian characters, it accepted just 110 character.
So please let know if anyone can clarify me the limit for indexed field in Progress 9.1D.

Thanks,
Pavan

 

[RealHeavyDude]

The limit of character fields which you can index is on bytes - not on characters. Whether a character is using 1 or more bytes to be stored in the database is determined by the code page you use. If you are using just the ASCII characters then the number of bytes will equal the number of characters, but, if you are using UTF-8 (Unicode, I am not familiar with Russian code pages) then it might very well be that some of the characters you store will use more than one byte which explains the behavior you experience.

BTW, 9.1D is stone age software - you should upgrade to a recent version of OpenEdge for which this limit was increased dramatically.

Heavy Regards, RealHeavyDude.

 

[Pavan Yadav]

Thanks a lot dude... That might be the reason only ...!!

& well, we are planning to move away from 9.1D for long time, & finally started moving the application to Oracle instead of higher version
Because as per PSC, our some of the programs might not work if we upgrades our Progress version.

 

[RealHeavyDude]

That is the first time that I head something like that from PSC. Usually upgrading to OpenEdge is a compile-and-go, even from Progress V8. Having said that, it is true, there might be minor issues you need to fix and if you are using some of the infamous frameworks from PSC (ADM2 or Dynamics) chances are you are not upgrading the right way - but that's another story.

Heavy Regards, RealHeavyDude.

 

[MaximMonin]

utf-8 for russian characters - 3bytes per char.
1251/ibm866 for russian characters - 1 byte per char.

 

[Pavan Yadav]

Thanks Maxim... Thanks Dude..
Well, is there any way to check the bytes in particular field. Till now I was using the function Length and comparing it as 188 char.
But is there any way I can validate the same Progress limitation if I am storing non ASCII values in char field. Because in that comparing Length(field) will not return the correct value.

 

[RealHeavyDude]

From the online help, but I don't know - as I have no Progress V9 at hand right now - whether this was already available in Proress V9:

LENGTH function
Returns the number of characters, bytes, or columns in a string, or returns the number of bytes in an expression of type RAW or a BLOB field, as an INTEGER value.
Syntax

LENGTH ( { string [ , type ] | raw-expression | blob-field } )

string
A character expression. The specified string can be a character string, a CLOB field, or a LONGCHAR variable. and may contain double-byte characters.
type
A character expression that indicates whether you want the length of string in character units, bytes, or columns. A double-byte character registers as one character unit. By default unit of measurement is character units.
There are three valid types: "CHARACTER," "RAW," and "COLUMN." The expression "CHARACTER" indicates that the length is measured in characters, including double-byte characters. The expression "RAW" indicates that the length is measured in bytes. The expression "COLUMN" indicates that the length is measured in display or print character-columns. If you specify the type as a constant expression, ABL validates the type specification at compile time. If you specify the type as a non-constant expression, the AVM validates the type specification at run time.

Note:

The expression "COLUMN" is not valid for a LONGCHAR variable or a CLOB field.

raw-expression
A function or variable name that returns a raw value.
blob-field
An expression that evaluates to a BLOB field.

Heavy Regards, RealHeavyDude.