This content has been marked as final. Show 6 replies
I'm afraid you are struggling with a database issue. Even though 4000 characters is the maximum possible length, due to Unicode strings (where 1 char needs 2 bytes), the effective maximum is actually just 2000 chars. Ask first DB gurus what issues/resolutions are known, or just re-implement your requirement so that it respects the 2000 maximum.
OK. I will try to guess the reason:
4000 characters in plain ASCII (like a text in English) can really be stored in a database VARCHAR2 field
The problem occurs if an international character appears - this is either converted to ASCII, replaced by a ?, or you can define encoding of the database to Unicode which uses 2 bytes per character - therefore a VARCHAR2 can have maximum 2000 (Unicode) chars
Now, even if you store plain English chars in a 4000-char VARCHAR2, something on the way might expect Unicodes - therefore, the ending 2000 chars are most likely thrown away.
You might try to find the way how to suppress "something on the way" - this might require contacting the development, unless someone knows about a parameter that might configure that (I don't).
I'd recommend a different approach - why on Earth do you need a (searchable!) metadata field longer than 2000 characters? Isn't there another way of doing it? Would you mind sharing your use case? Maybe someone will know...
Try setting "MemoFieldSize=4000" in config.cfg and restarting the Content Server. You may want to rebuild the search index.
Then, as a test, create a totally new memo field and see if 4000 characters can be returned in the new field. You may end up having to drop the old field and recreating it if the new field works, but the old one doesn't.
thanks for sharing your never ending knowledge.
Anyway, I'm still curious what could be the scenario. I thought of the following:
- no user will want to type 2000+ characters to search for anything. Therefore, the field might be auto-read (like from a 2D barcode), or more likely contains a cumulative info (like comma- or space-separated strings).
- alternatively, the field might contain a text that could be fulltext-searched (like an annotation)
For the cumulative scenario I immediately think of tagging or keywords, and there are OOTB means how to tackle these.
For the fulltext or barcode scenarios I wonder why 2000 is not enough and 4000 is. Either way, for these I believe rather than a metadata field, it should be stored in a separate content item (CLOB in the database, not VARCHAR2), that is linked to the root.