@hkeric.wci - Can you expand on the invalid hex characters? We’ve had multi-company crashing for a long time, to the point where I was running data fixes weekly (and now daily with v2022.2.8). Thanks!
1 Like
Amen @hkeric.wci I miss the good old days of searching through notepad++ files to find invalid characters part descriptions. Excel for Mac used to ruin my life.
“Let’s address one end at a time…”
ASCII chars with a code less than 32 (0x20) are control codes, and not typically considered “printable characters”. I’ve found the RS (Record Separater, code 30 or 0x1E in hex) in data brought over from Excel. That’s caused us some problems.
Anything in the range of 32 to 126 should be fine.
So gotchas that come to mind are (only decimal values shown)
160 - a nonbreakable space
150 - the ‘en dash’
151 - the ‘em dash’
Most of those work their way into the DB by being copied from a website, or a pdf.
2 Likes
You can hand out the one-pager “special characters to be avoided…” and tell people it should be applied to ANY key data field (I think we got this from the old EpicWeb site). I’m still looking for someone to code shock collars when these characters are used, but that’s off topic 
Configurator Special Characters.pdf (68.0 KB)
fixed it
- "Your Part is average costed…Do you really want to put the bin into -ve?..
1 Like
Other than whitespace characters, that special characters list is effectively a list of C# (and others…) operators and expressions! Little Bobby Tables strikes again?
Jenn - I take exception to avoiding a hyphen - in a part number. I could see making it a no-no to lead or end with a hyphen, but to not be able to use one in the middle of part number is a deal breaker for most folks. Especially if your configurator makes an intelligent P/N where fields are delimited by the hyphen.
Right, that’s the oddest one, but I’ve seen this advice before. In the back of my mind, it has to do with possible GL account separators, and I know it makes no sense. I’m trying to find that discussion here…
We actually do use the hyphen . I’ve been through several part conversions and seen spaces, %, and *. Those are the ones that make me shudder. I forgot the list said to avoid hyphens.
Best I could find was the idea that a dynamic GL segment can be a part number. So if you use hyphens as the segment separators AND hyphens in your part numbers, this would get confusing at best.
Edit - oh here it is:
I inherited a system that had part numbers like: 3/8" EYEBOLT
in before …
I know what many of us think about the topic but @JasonMcD is this an Idea yet? I have votes I can cast toward it and it looks like it’d have a bunch of support from other folks here. A community effort is fine and all but ultimately having the core business logic do this would reach more customers.
List of Hex Characters that will cause your Epicor Multi-Company to crash… You will need to prevent it on GlbPart and Part for example. You can make a List and then there is a LINQ one liner to trim them, I am not on PC. But thats it in a Nutshell.
CHAR(0x1f)
CHAR(0x1a)
CHAR(0x1e)
CHAR(0x13)
CHAR(0x17)
CHAR(0x1d)
CHAR(0x1c)
CHAR(0x11)
CHAR(0x02)
CHAR(0x14)
CHAR(0x01)
2 Likes
Ah, no, not yet. I was trying to garner some anger support here before moving forward. Yes, I had a plan.
OK, I’ll go make the idea.
2 Likes
For providing the list
For them not being in order
Just curious … What collation does the Erp DB use?
Somebody, somewhere, must have pasted text with unicode characters into a field in Epicor.
Trying to understand this word from the googling.
Meaning, what is the sort order? Sorry, #NotACoder
Collations in SQL Server provide sorting rules, case, and accent sensitivity properties for your data . Collations that are used with character data types, such as char and varchar, dictate the code page and corresponding characters that can be represented for that data type.
In most basic terms how the data is encoded. The default for English (United States) is
SQL_Latin1_General_CP1_CI_AS