Developing for Microsoft Dynamics GP by David Musgrave (Australia) and the Microsoft Dynamics GP Developer Support Team (USA)Syndicated From: http://blogs.msdn.com/b/DevelopingForDynamicsGP/
Click on the link to see the full About Page.
Today, I came across an issue where a feature in Microsoft Dynamics GP would work when the workstation had its regional settings set to United States, but would fail to produce any data when the workstation had its regional setting set to Australia, New Zealand, United Kingdom, etc.
We have seen related issues where code would appear to work for the first 12 days of a month, but would generate errors on the 13th day of the month when using non United States regional settings.
We have also seen issues where errors get generated when there is a single quote character in data, or records beginning with Z failing to be included when processing or printing reports.
We have even seen issues where errors are generated when regional settings for time were altered so that the suffixes for 12 hour time were changed from AM and PM to A.M. and P.M.
All of these problems are caused when Dexterity code talks directly to SQL Server and best practices are not followed.
Note: All table access that is handled by Dexterity itself will correctly handle the issues that can cause the above mentioned problems.
However, the leverage the functionality of SQL to optimize performance, there are times where developers write Dexterity code that bypasses the Dexterity table handling and talks directly with the SQL Server.
There are many benefits that can gained when using SQL Where clauses with the Dexterity range table where command, when executing pass through SQL commands, or calling stored procedures. But there are some best practice methods which will avoid all of the problems mentioned above.
Here is a quick summary:
You might have seen all or some of this before, but just in case I wanted to highlight it again as I am still seeing code that does not follow these best practices and so fails under certain circumstances that the developer probably did not test for.
The following articles on this blog discuss related issues:
The following Knowledge Base articles also discuss these issues:
Hope this helps you write robust code for all regions and settings
Other Microsoft Sites
I'm a Customer
I'm a Partner
Follow Microsoft Dynamics