asked on

International Currency Format not updateing properly

I have attached a code snippet that creates the database and user that I am using to connect. My question is that since Portuguese (Brazil) regional settings use the format for currency values R $999.999.999,99 where the decimal separator is ',' and the thousand separator is '.' When i execute the insert statement as contained within the snippet, I get a value inserted into the database 23334.00 instead of the 233.34 as I would expect, since I am setting the language to Portuguese prior to issuing the command.

I have similar results when issuing the update statement:

Update Test
Set CurrencyValue = '$223,33'
Where RecordID = 1

Obviously, if I don't put the single quotes around the dollar amount, I get an error saying that there are too many parameters for the inset query, and in the update statement from above I get an error saying 'Syntax error near 33', which comes from the ',33' portion of the update statement.

Any help would be greatly appreciated.

Thanks,

William
(william@melvinconsultinggroup.com)

-- SQL script
 
USE [master]
GO
/****** Object:  Database [test_db]    Script Date: 06/13/2008 13:11:25 ******/
CREATE DATABASE [test_db] ON  PRIMARY 
( NAME = N'test_db', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\test_db.mdf' , SIZE = 2048KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB )
 LOG ON 
( NAME = N'test_db_log', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\test_db_log.ldf' , SIZE = 1024KB , MAXSIZE = 2048GB , FILEGROWTH = 10%)
GO
EXEC dbo.sp_dbcmptlevel @dbname=N'test_db', @new_cmptlevel=90
GO
IF (1 = FULLTEXTSERVICEPROPERTY('IsFullTextInstalled'))
begin
EXEC [test_db].[dbo].[sp_fulltext_database] @action = 'disable'
end
GO
ALTER DATABASE [test_db] SET ANSI_NULL_DEFAULT OFF 
GO
ALTER DATABASE [test_db] SET ANSI_NULLS OFF 
GO
ALTER DATABASE [test_db] SET ANSI_PADDING OFF 
GO
ALTER DATABASE [test_db] SET ANSI_WARNINGS OFF 
GO
ALTER DATABASE [test_db] SET ARITHABORT OFF 
GO
ALTER DATABASE [test_db] SET AUTO_CLOSE OFF 
GO
ALTER DATABASE [test_db] SET AUTO_CREATE_STATISTICS ON 
GO
ALTER DATABASE [test_db] SET AUTO_SHRINK OFF 
GO
ALTER DATABASE [test_db] SET AUTO_UPDATE_STATISTICS ON 
GO
ALTER DATABASE [test_db] SET CURSOR_CLOSE_ON_COMMIT OFF 
GO
ALTER DATABASE [test_db] SET CURSOR_DEFAULT  GLOBAL 
GO
ALTER DATABASE [test_db] SET CONCAT_NULL_YIELDS_NULL OFF 
GO
ALTER DATABASE [test_db] SET NUMERIC_ROUNDABORT OFF 
GO
ALTER DATABASE [test_db] SET QUOTED_IDENTIFIER OFF 
GO
ALTER DATABASE [test_db] SET RECURSIVE_TRIGGERS OFF 
GO
ALTER DATABASE [test_db] SET  ENABLE_BROKER 
GO
ALTER DATABASE [test_db] SET AUTO_UPDATE_STATISTICS_ASYNC OFF 
GO
ALTER DATABASE [test_db] SET DATE_CORRELATION_OPTIMIZATION OFF 
GO
ALTER DATABASE [test_db] SET TRUSTWORTHY OFF 
GO
ALTER DATABASE [test_db] SET ALLOW_SNAPSHOT_ISOLATION OFF 
GO
ALTER DATABASE [test_db] SET PARAMETERIZATION SIMPLE 
GO
ALTER DATABASE [test_db] SET  READ_WRITE 
GO
ALTER DATABASE [test_db] SET RECOVERY SIMPLE 
GO
ALTER DATABASE [test_db] SET  MULTI_USER 
GO
ALTER DATABASE [test_db] SET PAGE_VERIFY CHECKSUM  
GO
ALTER DATABASE [test_db] SET DB_CHAINING OFF 
 
USE [test_db]
GO
/****** Object:  User [cwxsa]    Script Date: 06/13/2008 13:10:57 ******/
CREATE USER [cwxsa] FOR LOGIN [cwxsa] WITH DEFAULT_SCHEMA=[dbo]
GO
/****** Object:  Table [dbo].[test]    Script Date: 06/13/2008 13:10:57 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[test](
	[RecordID] [int] IDENTITY(1,1) NOT NULL,
	[StringValue] [varchar](100) NOT NULL CONSTRAINT [DF_test_StringValue]  DEFAULT (''),
	[CurrencyValue] [money] NOT NULL CONSTRAINT [DF_test_CurrencyValue]  DEFAULT ((0.00)),
	[DateValue] [datetime] NOT NULL CONSTRAINT [DF_test_DateValue]  DEFAULT (((1900)-(1))-(1))
) ON [PRIMARY]
GO
SET ANSI_PADDING OFF
GO
 
-- End SQL Script
 
 
 
-- SQL script to insert Currency value
 
SET LANGUAGE Portuguese
 
Insert Into Test (StringValue, DateValue, CurrencyValue) Values
('String Value 1', '03/03/2008', '233,34')

Open in new window

ASKER CERTIFIED SOLUTION

dportas

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

william_melvin

ASKER

Thanks for the response, dportas,

I think I may not have explained the issue very well apparently. When the application creates the SQL Insert or Update statement it will use the regional settings as defined on the client. In the case of this app, some workstations are deployed in Brazil and Argentina, which means that their regional settings will be configured like so:

Format: Portuguese (Brazil)
Number: 123.456.789,00
Currency : R$ 123.456.789,00
...

The issue is that when the workstation goes to format a number when inserting it into a sql query it will format the number using the decimal separator of ',' (comma) rather than '.' (period).

In the snippet above I referenced code that said this:

Update Test
Set CurrencyValue = '$223,33'
Where RecordID = 1

I would like to have it look like this and work:

Update Test
Set CurrencyValue = $223,33
Where RecordID = 1

But this doesn't work because the SQL parser will give the message:

Msg 102, Level 15, State 1, Line 2
Incorrect syntax near '33'.

This is because it recognizes the ,33 as another field / value pair to update, rather than the correct interpretation of ,33 being a cents portion of the money amount.

If I put the 223,33 in single quotes then it will write to the database, but at that point it will write the value as 22333.0000. My hope was that there would be a way at the database level to catch and format those currency or numeric amounts correctly, or that SQL server would understand that in this particular environment, the SQL Server machine, Client machines and SQL Server versions are all configured with language settings set for Portuguese (Brazil). According to the MSDN site, setting the language to Portuguese should force the SQL server to use date and currency formatting based on those regional settings (as identified above).

One more peice of information, I did go back to my change the above update statement to this:

Update Test
Set CurrencyValue = Convert(money, $223,33)
Where RecrodID = 1

Which works, but updates the value to 223.00 and drops the cents portion of the amount (the ,33).

Again, thanks for you response, and if you have any other comments and suggestions, please let me know.

William

william_melvin

ASKER

I do appreciate your response, and since you are the only one that responded, I am accepting the answer. I am now going back to the old VB code and will correct the issue there. It is very difficult to believe that Microsoft insists on forcing currency formats to the US standard of using a decimal point rather than correctly using the format specified by the Regional settings.

Again, thanks for your answer.

William

dportas

I still don't understand why your client application needs to create STRINGS instead of NUMERICs for currency data. If you handle your parameters as NUMERICs then all the localization can be taken care of automatically. Your examples don't really tell us much because they don't contain any parameters.

Your problem is apparently caused because you treat numeric data as strings, in which case you have no option but to handle the regional settings yourself.

william_melvin

ASKER

I am just not explaining it correctly. The regional settings are working great on the workstation. They format the number exactly as expected, 223,22.

The problem is that if you open up your SQL Query tool and select a field in any database that is defined as currency and type the following commend:

Update tablename
Set fieldname = 223,22

You will get an error, no matter how the regional setting on your server are configured. What I would expect is that when SQL server is installed in a county where the , is defined as the decimal separator, then SQL server would be able to understand that 223,22 is two-hundred twenty-three dollars and 22 cents. That is what I would expect from SQL server, but alas, Microsoft is apparently not capable of understanding that so I will handle it in code.

But like I said earlier, it is not that big of a deal. I can modify the code to change the numeric amount to a US format (i.e. decimal point as the decimal separator ) and not use the local numeric formatting.

Thanks again for your responses.

William

dportas

>> The problem is that if you open up your SQL Query tool...

Yes but that's not the problem you described before. Your APPLICATION should not be creating such SQL statements. Your application should use proper numerics and pass them as NUMERIC parameters either to inline SQL - or better still to a stored procedure. If you do that then your code should execute just fine under any regional setting.