Ignore them at your peril.

So you may not run into issue immediately but there are good reasons that some of those characters are restricted.    Some of the reasons have to do with the behavior in SQL.   

Here is an example i found that was more eloquent than me "For example - if you have a part description of 12' X 8'' to be 12 feet by 8 inches- on SQL it will take that apostrophe and consider that the end of the statement and will give you unpredictable results. Could also raise errors with the software on search functions as these are SQL or select statements on the back end that return the information to you."

Other special characters can trigger similar issues.

Some characters like “/ — ;” are interpreted by the SQL server as a syntax and can be treated as an SQL injection attack when added as part of the input.   It's remote that it would happen unless your server is exposed to the outside world but Sage can't leave the system vulnerable.

We just went through a conversion where another consultant thought it was fine to allow special characters in some fields.   The results weren't that pretty.   I was working with conversion code written by the brilliant Dave Padgett of Procession Software and he had wisely written code to replace all special characters as Sage suggested.   I should have paid more attention to Dave's code and stopped this.  

So you might never have an issue but Sage can't take that chance.   

Well said! It definitely makes sense and I can see how it could work a few times and break later down the road - I’ve seen this with quick fixes.  Thank you for your reply!! I’ll share it with my team :)

Here's more to share.  One of my staff, Chat GeePeeTee, did this for me. 

In Microsoft SQL Server, there are certain special characters that you should be cautious about, especially when working with data and constructing queries. These characters may have special meanings in SQL syntax and could potentially lead to SQL injection attacks or unintended consequences. Here are some characters to be cautious about:

1. Single Quotes (')

1. • Example: SELECT * FROM TableName WHERE ColumnName = 'Value';
   • The single quote is used to denote string literals in SQL. If not handled properly, it can be exploited for SQL injection.

1. Double Quotes (")

1. • Example: SELECT * FROM "TableName";
   • In SQL Server, double quotes are used to delimit identifiers (like column or table names) with spaces or special characters. However, it's safer to use square brackets for this purpose.

1. Semicolon (;)

1. • Example: SELECT * FROM TableName; DELETE FROM AnotherTable;
   • The semicolon is used to terminate SQL statements. Multiple statements can be executed in one batch separated by semicolons. Be careful when concatenating user inputs into SQL queries to prevent unintended execution of multiple statements.

1. Percent Sign (%)

1. • Example: SELECT * FROM TableName WHERE ColumnName LIKE '%value%';
   • The percent sign is used in the LIKE clause as a wildcard character. It can lead to unexpected results if not used correctly.

1. Ampersand (&)

1. • Example: SELECT * FROM TableName WHERE ColumnName = 'Value' & 'AnotherValue';
   • In SQL Server, the ampersand is used for bitwise operations. Avoid using it inappropriately in string concatenation.

1. Dash (-)

1. • Example: SELECT Column1 - Column2 AS Result FROM TableName;
   • The dash is used for subtraction in SQL. Be cautious when using it in expressions or constructing dynamic queries.

1. Forward Slash (/) and Backslash (\)

1. • Example: SELECT * FROM TableName WHERE ColumnName = 'Value/' OR ColumnName = 'Value\';
   • These characters can be used for escaping or as part of file paths. Be careful when dealing with these in string literals.

1. Brackets ([])

1. • Example: SELECT [Column Name] FROM [Table Name];
   • While brackets are used to delimit identifiers in SQL Server, using them directly with user inputs can be risky. It's safer to validate and sanitize inputs.

Always use parameterized queries or prepared statements to mitigate the risk of SQL injection attacks, and validate and sanitize user inputs before incorporating them into SQL queries.

That's funny, we have a team member with that same name! :0)

Thanks for both variations of the answer. I'm leaning towards having two fields for the products or customers where we are 100% against changing the formats. One field would be an exportable/query friendly field that carries no special characters at all. The other field would carry special characters but not get pulled into queries or exports. This field can however be tagged in Crystal (forms/'pretty' reports) and website pulls. The primary concern here is how we would invoice for a licensed product where the license itself carries a trademarked sign like & or %. The two fields would serve as a way to deal w/ export concerns and license concerns. Of course, this would have to carry a lot of various tests to see if this would work, but I'm a meet in the middle kind of person. And, if testing proves a bust - we're already directing our Data Team to adjust characters like " for Inch to be converted to in and so on ;)