MAXLEN error on saving %Persistent class

Question

Question

Tirthankar Bachhar · Dec 3, 2018

Hi,

When we define a %String property, and don't mention any MAXLEN, by default it uses 50 as defined in class %Library.String.

As a result, when we try to save data more than 50 characters, it fails with below error.

ERROR #7201: Datatype value 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' length longer than MAXLEN allowed of 50

This is very challenging when we parse data and tries to store it in SDA3 structure, because in many places its always set to 50, which is not enough.

We have been fighting a lot to avoid MAXLEN error in various scenarios and in various part of the products over a long period of times.

The general solution we have been opting so far is, whenever we encounter this error, we make that string property to use MAXLEN=””.

Now, this is a kind of hit and trial method, and exhaustive in order to change so many properties in SDA3 structure.

What if we persists this class %Library.String in our product git, with below code change.

I know it is not recommended at all to change any library class, but without this there is no other solution.

We just need to be cautious about HSF upgrade, and make sure we take the latest and check in to our git with the below change all the time.

Benefit: WE WILL NEVER ENCOUNTER MAXLEN ERROR

Class: %Library.String

Currently it is:

/// The maximum number of characters the string can contain.
Parameter MAXLEN As INTEGER = 50;

We change it to:

/// The maximum number of characters the string can contain.
Parameter MAXLEN As INTEGER;

*** Do you see any drawback or issues with this? Can there be any other impact due to this?

Discussion (12)2

Log in or sign up to continue

Eduard Lebedyuk · Dec 3, 2018

*** Do you see any drawback or issues with this? Can there be any other impact due to this?

This is absolutely not a recommended approach.

Here's how you can do it.

Create your own class MyString that extends %String and specifies MAXLEN parameter (I recommend 5000 or 10000, but something specific in any case).
Use %Dictionary package to iterate over all your persistent classes. In there:
- open each class
- iterate over its properties
- change %String type if found to MyString
- save class
Recompile modified classes.

10 0

score 1 · Answer 1 · 2018-12-03T10:07:36-05:00

Neerav Adam Verma · Dec 3, 2018

Why dont you just do

Property Abc as %String (Maxlen = 5000)

or use %Text

1 0

score 1 · Answer 2 · 2018-12-03T11:11:55-05:00

Setting MAXLEN="" or MAXLEN=5000 absolutely resolves the issue related to that specific property. But what about other potential huge list of properties within SDA3 structure?

Please read my whole notes.

score 1 · Answer 3 · 2018-12-03T11:12:10-05:00

Setting MAXLEN="" or MAXLEN=5000 absolutely resolves the issue related to that specific property. But what about other potential huge list of properties within SDA3 structure?

Please read my whole notes.

score 0 · Answer 4 · 2018-12-04T06:26:10-05:00

Thank you, this helps. Because the number of classes are huge. Also, I don't think we need to create a new datatype as Vitaliy Serdtsev mentioned about the class %VarString.

score 0 · Answer 5 · 2018-12-04T06:49:08-05:00

Hi Vitaliy,

Thank you for sharing this option; didn't notice the moment when this class emerged. Just found that it exists in Caché 2015.1-2018.1. Not sure how would it work with ODBC/JDBC, but it's up to OP to check this stuff if he needs it.

score 1 · Answer 6 · 2018-12-03T10:22:47-05:00

Robert Cemper · Dec 3, 2018

use %String(MAXLEN="")

1 0

score 0 · Answer 7 · 2018-12-03T11:28:30-05:00

If you don't define an explicit MAXLEN it is just ignored during validation.
But you may run into problems with ODBC/JDBC when your VARCHAR or similar just has no maximum SIZE.

So you might instead store your super-long-string into a GlobalStream
But then you lose all string related operations. It's an option I personally dislike.

score 0 · Answer 8 · 2018-12-03T13:48:47-05:00

Ok I thought its about just one property. If it's a more generic problem then you should define your own String class extending %Library.String. Here you can not only have the cache params but even your own params related to sda3.

This also can be done for all datatypes if you do need.

score 0 · Answer 9 · 2018-12-04T06:27:43-05:00

I don't think we need to create a new datatype as Vitaliy Serdtsev mentioned about the class %VarString.

Sure if you have this class, it's better to use it.

score 1 · Answer 10 · 2018-12-03T23:26:30-05:00

Tirtha the best way to deal with this is to create your own class that extends %String (specify MAXLEN parameter to say 15000) and then change all your persistent classes to override %String with what you just created. Sure this is more work but this is safer and hence is recommended.

score 3 · Answer 11 · 2018-12-04T01:16:32-05:00

Vitaliy Serdtsev · Dec 4, 2018

use %VarString

3 0