We have moved to GitHub Issues
Created by Tom Fulton 13 Sep 2012, 15:19:33 Updated by Sebastiaan Janssen 08 Nov 2017, 08:37:24Tags: Unscheduled PR
Subtask of: U4-9609
Currently the Textstring datatype supports up to 500 characters, but allows you to add more. If you add more and attempt to save, you get the following error (YSOD):
String or binary data would be truncated. The statement has been terminated.
This is because it's using Nvarchar(500) for it's column type.
This might be an edge case, but we had a client attempt to enter more than 500 characters in the textbox and receive the above error.
I'd like to propose the possibility of adding a MaxLength or similar attribute to prevent users from adding more than 500 characters and thus preventing the above error.
Pull request available here: http://umbraco.codeplex.com/SourceControl/network/forks/michielvoo/UmbracoU4854/contribution/3477
Ismail going to work on this for hackathon.
Patches from hackday.
Patch take 2 Sorry, I didn't spot bug in original pull request.
Hey lesley, thanks for cleaning this up.
But the 450 max length is deliberate. There's a possibility that a String.Replace() happens elsewhere, which will still make the string longer that 500. There is a hardcoded check for CDATA elements in multiline text fields, which will be expanded to and . So you should repatch to make sure that actual length never exceeds 500. The 450 number is just to be on the safe side, hypothetically there's no correct workaround, because the text field could have multiple CDATA elements. :-(
Keeping this one as In progress as I'm not too happy with the current solution. Would like to see a new (single) patch that adds maxlength to the textbox, and some server side validation.
I think it should be pretty easy to test before submitting to the database if the string is longer than 500 characters and if it is then you can return a validation error.
You're absolutely right, I wasn't too happy with my solution either, thanks for being critical.
But then for a solution we need to back track even further, because any time nvarchar is used as the backing store for a property, it needs to be validated that the value doesn't exceed 500 characters. I haven't looked into the validation of Umbraco properties, and how to surface validation errors back to the UI. But from what I could tell, the editors themselves don't know if they are being used for an nvarchar, they just expose their value.
As far as I could tell, at the point where you would actually know that you're going to save as an nvarchar, it's too late to do regular field validation (the one where you get the red notification at the top of editor interface). So we'd have to cancel the saving all together, and display an error message in a balloon, if that is at least possible.
Are my assumptions correct? If so, I'd be happy to 'repatch' it like that.
@Michiel I THINK you should be able to do server side validation that does return the red notification, would be awesome if you could look into that. If not, then we'll need to rethink this. I think you could at least have a look at the prevalues of this datatype, they should list the fact that we're trying to store it in an nvarchar.
Perhaps this topic can help with server side validation: http://our.umbraco.org/forum/developers/extending-umbraco/7085-Linked-mandatory-datatypes#comment25937
Still seeing this issue in version 7.
Closing issue due to inactivity - see blog post for details https://umbraco.com/blog/issue-tracker-cleanup/
Still a very useful feature for both the Textstring and Textarea data types.
While we're at it, perhaps show a countdown of characters remaining.
And further... allow the length to be user configurable (up to the maxLenght value). Set to 140 characters if using it for a tweet, for instance. Would make the whole experience for users much better. So many reasons to want to specify a maximum length for entry in textstring and textarea properties!
PR for this here --> https://github.com/umbraco/Umbraco-CMS/pull/2294 :)
Type: Feature (request)
Difficulty: Very Easy
Backwards Compatible: True
Fix Submitted: Pull request
Affected versions: 7.6.3
Due in version: 7.7.5, 7.6.12
Sprint: Sprint 71