Select the product you need help with
- Internet Explorer
- Windows Phone
- More products
BUG: Changed Locale Settings in Extended Stored Procedure May Cause Incorrect Results
Article ID: 246199 - View products that this article applies to.
This article was previously published under Q246199
BUG #: 18859 (SQLBUG_65)
BUG #: 56451 (SQLBUG_70)
BUG #: 213085 (SHILOH)
Any code that changes the locale settings and that runs in an extended stored procedure, may cause SQL Server to interpret numbers incorrectly. The symptoms may vary widely depending on the exact circumstances but do include the following:
Locale settings are process-wide. These settings are used by SQL Server to convert strings (such as literals in Transact-SQL statements) to numbers. Every Win32 process is initialized with the ANSI-C settings; these are the correct settings for interpreting numbers in Transact-SQL statements. For example, the decimal separator is point ("."), and so on.
Any changes to the locale settings of an extended stored procedure affect the way SQL Server converts strings to numbers. For example, an extended stored procedure calling "setlocale(LC_ALL, "")" sets the locale setting to the regional settings of the process owner, and thus exhibits this problem.
If this problem happens with an extended stored procedure and you own the source code, you can avoid changing the locale settings within your code. If that is not possible, you can reset the locale settings to ANSI-C before you return from your extended stored procedure. For example, by calling "setlocale( LC_ALL, "C" );".
In the scenario described in the "More Information" section, suppose the following:
Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article.
Steps to Reproduce Behavior