Previously to 2024.2, x(1000) fields took a large amount of characters (had not run into any limit thus far)
2024.2 front end seems to be taking the (1000 character) limit literally, and when pulling a BoM into Engineering Workbench, the field goes red at 1000 characters and doesn’t allow further editing.
Opening App Studio and changing the max characters in the field to 100000 seems to override successfully and allow data input.
Anyone else seeing this behavior? We use ECOOpr.CommentText for work instructions on our traveler and we have many BoMs >1000 chars in this field.
1 Like
I haven’t confirmed this behavior, but if true, hopefully someone just didn’t get the memo.
Epicor has always considered x(1000) to be nvarchar(max).
I’d report it.
I opened a case, which was quickly suggested for resolution… the response was, surprising to say the least…
TL;DR: It was broke before when it allowed you to input more than 1000 characters, we fixed it. Working as intended.
Thank you for contacting Epicor Support.
This issue that you have logged has been reviewed by our development team previously.
According to dev, this max length property is functioning as expected.
The workaround that you are using now is acceptable if you need to increase the max character.
The fact that it allows more that 1000 character previously is actually a bug and should not be taken into consideration.
Hope this information explains.
Please let us know should you have any further query.
3 Likes
I would not accept that. That is not consistent with prior behavior or advice from Epicor’s mouth themselves.
I missed this part →
At least we can do something.
1 Like
I inquired as to DMT behavior and asked if the x(1000) enforcement would take effect here as well. The issue was passed on to another team for further evaluation regarding DMT… Let’s see if that gets some other response!
1 Like
See this is crazy. Why fix things that are not broken? When the list of things that actually do not work properly is endless? see: Epicor ideas.
9 Likes
I assume this “fix” also means if you had more than 1000 characters in one of those fields that the extra data is now gone and not recoverable.
Well if changing the settings in the UI is a workaround that means they didn’t actually change the database schema.
4 Likes
Further reply from Dev: Kick rocks.
Hello Gabriel,
I have linked to this case PRB0290842, which has already addressed the condition you are reporting on this case.
Our Development Group has confirmed this application behavior is intended and correct, as the default max-length is set to 1,000 characters in the regular form, but users can adjust it to a different value if necessary using the max-length property.
I have tested this and it works correct. There is no customization needed. Please follow this steps:
- Go to Extended Properties (System Setup > System Maintenance > Extended Properties)
- Enter table “ECOOpr”
- Got o field “CommentText”
- In the “Format” field, enter ‘x(10000)’ or the maximum length you need.
After this, log out, and then log back in. You should be able to add more than 1,000 characters in the Operation Comments.
Again, this behavior has been confirmed by Development to be working correctly in PRB0290842 (you may review the linked PRB). The correct way to add more characters to your operation comments is the one I described above.
4 Likes
I’d have cried bloody murder! LOL. No, the back-end stuff remains untouched thankfully. But the front end is now picky!
2 Likes
That’s one good thing… as long as no one saves the now shortened field when they exit and it asks them if they would like to save…
Observed Behavior is that the field highlights red as the character limit has been exceeded. (This happens as soon as you load a record with >1000 chars in that field and click the input box)
Does not allow save while red. Does not allow any further data entry, but does allow the data to be highlighted and deleted, which then allows data entry of <1001 chars. Field goes red as soon as you hit the 1000th char.
So, thankfully nothing obvious that’s going to result in data loss, just a pain in the patooie!
1 Like
That’s a good thing then. Looks like some forethought did go into it. Glad to hear that.
So for what it’s worth, this solution does work, but wouldn’t you also have to do the same thing on PartOpr and JobOper and . . . not sure where else?
1 Like
What about all of Epicor’s comment fields that are set at x(1000)?
It’s always been intended at max, now it’s going to limit it, surely they haven’t thought this out.
I mean, x(1000) is literally how we define a max field when we make one. Who would want to change it for the UI and somehow think that makes sense?
@Rich , @pferrington ?
1 Like
I agree, and how is x(10000) any different than x(1000) both are still just placeholders for varchar(max).
2 Likes
OrderHed.OrderComment, OrderHed.PickListComment, OrderHed.InvoiceComment, OrderHed.ShipComment, OrderDtl.OrderComment, OrderDtl.PickListComment, OrderDtl.InvoiceComment, OrderDtl.ShipComment… that’s from a single UI.
Those don’t all flow from ecoopr though?
Just checked, every field in the Epicor database named CommentText is nvarchar(max). The constraint is only at the client. Not really something they can change at the database without breaking someone’s existing use case.
Ah, what’s six orders of magnitude between friends?
2 Likes