More details on error "String or Binary data is truncated"

By Ravi V on 3 Jun

Most of us have seen this error on our application screens. Most of the times we receive this error when we are trying to insert data of length more than what is defined in database table.

If this is the case, Service Center should display more details on what column data is causing this error

Ravi -

That is just an error coming from the database and OutSystems is passing it up.

You should almost never be directly calling the CRUD actions anyways, you should wrap them in something that performs validations. That would be the place to check data length and return a friendlier error message if you want one.

J.Ja

Alternatively, since the Platform knows the length of the Attribute and also knows the length of the string or binary that's being saved, it could perhaps check itself?

I've thought about that as well. It's not hard to make a universal checker for this either way.

But... and this is a BIG but... ever ask yourself "why is the error message from the DB so useless?" It's because DBs don't like to give away information to attackers about column names, table names, etc. A more detailed message may be a security issue. That's why I'm pretty fine with the current implementation, even though it is frustrating from time to time.

J.Ja

I'm fine with a cryptic message, as long as there's some logging in the error log or the like with more details (assuming that someone who has access to the error log doesn't pose a security problem :)).

Ravi V7 Jun

Also this problem is very severe and difficult to debug when a particular table is having large number of columns and you do not know which column is throwing this error while importing a large set of data from excel into the system. A little more help from platform about row number or column name from excel to pinpoint to exact details would be really useful.

I never have real problems with this error. The error in ServiceCenter drills down to the used entity and from there is just checking which (text) attribute can have the wrong input.

More information would be nice, but then you're comming into the security part what Justin has mentioned.