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 :)

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 ;)