Introduction
Sage 300 supports English, French, Spanish, Traditional Chinese, and Simplified Chinese languages.
Customers, using non-English languages in the Web Screens, may encounter pain points in the following areas:
- Different languages between the SQL Server database and the application server's system locale
- Different languages between the Sage 300 user’s language (locale) and the application server's system locale
- Non-English characters in key or coded fields
Sage 300 Architecture
The SQL Server database tables for Sage 300 are not configured for Unicode support, and non-English characters are saved as ASCII in the database. The business views, which handle all database transactions and business logic, rely on the locale setting to convert the characters. As such,
- The application server's system locale must match the same language as the data in the database
- The database collation should also match for proper sorting in that language
- The Sage 300 user's language setting changes the Culture (locale) of their session in Web Screens
Pain Points
- Different languages between the SQL Server database and the application server's system locale:
- For the French and Spanish languages, since they are a Latin language like English, using any of these languages with a Latin database collation successfully performs any character conversion and is therefore supported
- For the Chinese languages, the character conversion fails, resulting in displays of question marks (“?”) and is therefore not supported
- Different languages between the Sage 300 user’s language (locale) and the application server's system locale:
-
- For French and Spanish, since they are a Latin language like English, using any of these languages successfully performs any character conversion and is therefore supported
- For the Chinese languages
- Desktop (for comparison only)
- When a Chinese user and a Chinese locale is used, the Desktop sets the thread locale to use system locale so that all the subsequent data conversion between multibyte and wide characters will use the system locale where any character conversion is successful and is therefore supported. For example:
- Desktop (for comparison only)
-
-
-
- When an English user and a Chinese locale is used, the Desktop sets the thread locale to use the system locale where any character conversion is successful and is therefore supported. For example:
-
-
-
-
-
- When a Chinese user and an English locale is used, the Desktop sets the thread locale to use the system locale and any character conversion is unsuccessful and is therefore not supported. For example:
-
-
-
-
- Web Screens
- When a Chinese user and a Chinese locale is used, the Web Screens set the thread culture to use the user language so that any subsequent character conversions between multibyte and wide characters will use the user locale where the character conversion is successful and is therefore supported. For example:
- Web Screens
-
-
-
-
- When an English user and a Chinese locale is used, the Web Screens set the thread culture to use the user language and any character conversion is unsuccessful and is therefore not supported. For example:
-
-
-
-
-
- When a Chinese user and an English locale is used, the Web Screens set the thread culture to use the user language where the characters are then passed to the view where it sets the thread locale to the system locale where the character conversion is unsuccessful and is therefore not supported. For example:
-
-
3. Non-English characters in key or coded fields:
-
- For the French and Spanish languages, since they are a Latin language like English, using any of these languages successfully performs any character conversion and is therefore supported
- For the Chinese languages
- Desktop (for comparison only)
- In most screens when a user’s locale matches their system locale any character conversion is successful and is therefore supported.
- Web Screens
- Prior to the 2020 release, a regular expression statement was being used on certain fields to restrict characters based upon alphanumeric values “[A-Za-z0-9]”. However, this regular expression only allowed input of Latin-based alphanumeric characters.
- In the 2020 release, a new regular expression was implemented which allowed alphanumeric values within the user’s locale to be considered acceptable.
- However, certain underlying business views implemented their own restrictions which disallowed these newly acceptable characters. Thus, while these characters were now allowed to be entered, they were disallowed at the business view and/or database layer.
- For example, key fields using the "N" mask in the Desktop, French and Spanish users can enter and save French and Spanish accents with an English locale, but Chinese users can enter, but cannot save even in a Chinese locale server and database. The table below sums up the comparisons between the Desktop and the Web Screens using AP Vendors and AP Vendor Groups:
- However, certain underlying business views implemented their own restrictions which disallowed these newly acceptable characters. Thus, while these characters were now allowed to be entered, they were disallowed at the business view and/or database layer.
- Desktop (for comparison only)
Summary
While Sage 300 supports English, French, Spanish, Traditional Chinese, and Simplified Chinese languages, customers using non-English languages in the Web Screens may encounter pain points especially when the user language and locale settings do not match.
However, for French and Spanish languages since they are Latin-based can enter and save characters without restriction.
This article attempts to illustrate Sage 300’s support for Unicode characters in the Sage 300 Web Screens.
As a standard disclaimer, any topic in this article is subject to review and doesn’t represent a commitment as to when it will be available.