My data type in database is of type money, the problem is when I save value from user entered input (via a text-box) its not what I expected.
Example : string price = "199.99"; in the table it would save as 19999,0000
I tried Convert.ToDecimal("199.99"); and Convert.ToDouble("199.99"); the result is still the same.
What sql server dataype should i use for manipulating prices oriented data.
Thanks in advance.
The result of converting a string to double and/or decimal are dependent on the locale of your system, where the C# code is running. And the value inserted into the database depends on the type of parameter passed to the database and on the local settings on the backed database server.
So, what are they? Your locale, the type of parameter, the SQL Server server/database/connection settings?
Personally, I would prefer to use DECIMAL rather than MONEY.
See these two posts on sqlblog.
It somewhat looks like the currency symbol is set to European where the comma delimited the decimals... Is this possible?
Related
I have recently starter working with sql server instead of mysql.
I have a time column which I've noticed stores time as such: hh:mm:ss:nnnnnnn
Thing is I only want to to store hh:mm:ss, and I can't seem to figure out how to do that.
I do apologize if this is really obvious, I have had a long day and my searches did not return anything that helped.
time has a precision parameter which is "fractional second precision" so if you need hh:mm:ss you have to use time(0) as datatype
use the Time datatype which is available since 2008 onwards
If on SQL 2008, use the time datatype, and just store the hh:mm:ss; the nanoseconds will be 0. Just display the value back in the desired format in your presentation layer.
If on SQL 2005 (or older), you'll need to store the data as a datetime, and input the date version as some constant (usually 1900-01-01). Again, format the data at the presentation layer, not at the database.
I have the following query in MS Access and needs to be converted to SQL Server. I am trying to understand what does the format function do here and what is the use of "0".
SELECT Format([SumOfTotalPopulation],"0") AS Expr1 , SumOfTotalPopulation FROM
qry_ASSET_STREAM_DS_POP_PROP ;
Can anyone help me understad this. The above code is present in MS Access 2003 and Im working on SQL Server 2008 R2.
In your case, Format([SumOfTotalPopulation],"0") just removes the decimals from the number.
In SQL Server, you could use something like Str(sumOfTotalPopulation,12,0)
Or you could use Round()
The Access Format() function behaves differently based on the data type passed into it. In this example, I'm assuming that your SumOfTotalPopulation field is a number, which means that the formatting will be done as described here - basically, it will be formatted as an integer - no decimal point, no thousands separator.
The good news for you is that if the field in SQL Server is already defined as an integer type, you won't have to do this formatting. Otherwise, you should be doing this formatting at the presentation layer (user interface, web page, report, etc.) and not in the query itself.
Access teaches a lot of bad habits. Rather than translate what you have in Access one-for-one, take this opportunity to update things to be done "the SQL Server way" wherever possible.
I am trying do a query on a table via jdbc in my java program.
I know there are three rows in that table.
I've got the resultset, and can read and process data of the first row. but when I try to move the resultset to next row, an exception is thorwn.
the exception pointed [SQL0181]
You can use the SQL Message Finder to look up message codes.
The SQL0181 message text is:
Value in date, time, or timestamp string not valid.
This indicates you have a value in a row that can not be represented as an SQL Datetime value.
It is not uncommon for legacy HLL programs to introduce these sorts of errors as they are capable of writing directly to the table row without the same validation enforced by the SQL interface.
See also this previously asked SO question: Why am I getting a “[SQL0802] Data conversion of data mapping error” exception?
I know this is an old question, but it's a top search result for SQL0181, and the answers is wrong.
The problem is the date being retrieved can't be represented in the date format being used. The IBM i allows several non-ISO date formats, which can't handle things like the beginning & ending of time. The error stems from trying to use one of them.
You can either have your user profile changed or use ISO on your JDBC settings.
"jdbc:as400://RCHASSLH;date format=iso;time format=iso;"
ref:
http://www-01.ibm.com/support/docview.wss?uid=nas8N1017268
Currently, I am in the process of updating all of our Delphi 2007 code base to Delphi XE2. The biggest consideration is the ANSI to Unicode conversion, which we've dealt with by re-defining all base types (char/string) to ANSI types (ansichar/ansistring). This has worked in many of our programs, until I started working with the database.
The problem started when I converted a program that stores information read from a file into an SQL Server 2008 database. Suddenly simple queries that used a string to locate data would fail, such as:
SELECT id FROM table WHERE name = 'something'
The name field is a varchar. I found that I was able to complete the query successfully by prefixing the string name with an N. I was under the impression that varchar could only store ANSI characters, but it appears to be storing Unicode?
Some more information: the name field in Delphi is string[13], but I've tried dropping the [13]. The database collation is SQL_Latin1_General_CP1_CI_AS. We use ADO to interface with the database. The connection information is stored in the ODBC Administrator.
NOTE: I've solved my actual problem thanks to a bit of direction from Panagiotis. The name we read from our map file is an array[1..24] of AnsiChar. This value was being implicitly converted to string[13], which was including null characters. So a name with 5 characters was really being stored as the 5 characters + 8 null characters in the database.
varchar fields do NOT store Unicode characters. They store ASCII values in the codepage specified by the field's collation. SQL Server will try to convert characters to the correct codepage when you try to store Unicode or data from a different codepage. You can disable this feature but the best option is to avoid the whole mess by using nvarchar fields and UnicodeString in your application.
You mention that you changes all character types to ANSI, not UNICODE types in your application. If you want to use UNICODE you should be using a UNICODE type like UnicodeString. Otherwise your values will be converted to ANSI when they are sent to your server. This conversion is done by your code when you create the AnsiString that is sent to the server.
BTW, your select statement stores an ASCII value in the field. You have to prepend the value with N if you want to store it as a unicode value, eg.g
SELECT id FROM table WHERE name = N'something'
Even this will not guarantee that your data will reach the server in a Unicode form. If you store the statement in an AnsiString the entire statement is converted to ANSI before it is sent to the server. If your app makes a wrong conversion, you will end up with mangled data on the server.
The solution is very simple, just use parameterized statements to pass unicode values as unicode parameters and store them in NVarchar fields. It is much faster, avoids all conversion errors and prevents SQL injection attacks.
We have a problem affecting the production environment only.
We have a VB6/ASP website that allows for data in a database table to be hand edited.
It looks alot like an editable datagrid.
One of the editable columns is a date and when the record is saved dates day/month are being reversed.
03/11/2008 becomes 11/03/2008, if you were to resave the record the date is again 03/11/2008.
I have checked the DB value and it is indeed being reversed however the same identical code on the test systems does not do this.
So i'm very confident i'm looking for an environment change. The test system has the DB and Site hosted locally and in the live setup we have a separate web site server and database server. Where do you suggest I start looking for this problem. I've checked the regional settings on the servers and they are set to United Kingdom and the OS date format is correct.
This is SQL Server 2000. hit me with some ideas!.
Thanks :)
If you convert the user supplied string to a date before you feed it to the DB, then the Session.LCID of the thread executing your ASP page is responsible for how dates are interpreted.
If you feed the date as a string to SQL Server and let the conversion happen there, it will be useful to look into the SET DATEFORMAT and the SET LANGUAGE statements.
So here is my idea: Either stop using (encouraging your users to use) ambiguous date formats, and this problem will disappear, or make sure all links of the processing chain have a clear understanding on what format to expect.
This is almost certainly to do with either your machine or the db server being set to US date format. Double check both the system settings.
Alternatively, a quick Google search will bring up a few options for manipulating the data so it will do what you need.
How about the regional settings of the OS?
The following
select name ,alias, dateformat
from syslanguages
where langid =
(select value from master..sysconfigures
where comment = 'default language')
Returns the same result on test and live
us_english English mdy
The problem is the system cannot be redeployed to changed. I need to identify the cause and fix it.
Go into regedit and go to the following location in the Windows Registry:
HKEY_USERS.DEFAULT\Control Panel\International\
Check to make sure that the "sShortDate" field is correct.
The short date format stored in this location many times is different then the short date format stored in the Windows Control Panel/Regional Options. The short date in the regional options is for the user that you are logged into Windows as. The "sShortDate" field in HKEY_USERS in the short date format used by the Windows Services.