This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
T-SQL Cast versus Convert
What is the major difference between CAST and CONVERT in SQL cause both performs data type conversion?
CAST and CONVERT have similar functionality. CONVERT is specific to SQL Server, and allows for a greater breadth of flexibility when converting between date and time values, fractional numbers, and monetary signifiers. CAST is the more ANSI-standard of the two functions. Check this blog for examples of using both of those: http://sqltutorials.blogspot.com/2007/06/sql-cast-and-convert.html
The convert function can do more complex conversions, for example converting a datetime value into varchar using a specific format:
convert(varchar(16), dateTimeValue, 120)
Assuming you're talking about SQL Server.
From http://msdn.microsoft.com/en-us/library/ms187928.aspx and http://msdn.microsoft.com/en-us/library/aa226054(v=sql.80).aspx
Explicitly converts an expression of one data type to another. CAST and CONVERT provide similar functionality.
So yes, they are functionally the same. They just have different syntax that allows for more complex conversions or (subjectively) improved readability.
Related
I'm working with Amazon Athena and there are several columns that come out as scientific notation and I need it to come out as either an integer or a decimal. I've tried doing the answer from this: Convert exponential to number in sql
However, that doesn't work with SQL Presto, and this one doesn't work because I need it for multiple numbers, not just one: Query to convert exponential number to float in SQL Server
It should work if you cast the column to decimal.
SELECT CAST(doubleColumn AS decimal(22,2)) from my_table
There's no way to convert it globally.
I have always used CONVERT (and not CAST), as I assumed the former would recognize types and do an appropriate conversion where as the latter is simply trying to interpret a stream of bytes differently. But just learned that CAST=CONVERT for most purposes!
But can someone explain why the following happens. CAST produces different results for the same value (101), but represented differently - decimal (101) and hexadecimal (0x65) representations.
select cast(0x65 as varchar(5))
-----
e
select cast(101 as varchar(5))
-----
101
EDIT:
The query was run from SSMS.
I assume you are using SQL Server (where the confusion between the two functions would make sense).
That is simple. 0x defines a binary constant. 101 is a numeric constant. These are not the same thing.
When you convert a binary constant to a string, it attempts to interpret the constant as a character. When you convert a number to a string, SQL Server converts the decimal representation.
You can learn more about constants in the documentation.
You are trying to convert to completely different values. As Gordon mentioned, one is binary representation while the other is numeric.
But you need to note that there is some differences between CAST and CONVERT:
CAST is part of the ANSI-SQL specification; whereas, CONVERT is not. In fact, CONVERT is Microsoft SQL Server implementation specific.
CONVERT differences lie in that it accepts an optional style
parameter which is used for formatting.
Read more here: https://www.essentialsql.com/what-is-the-difference-between-cast-and-convert/
I'm taking an advanced SQL course in Oracle and we have been discussing various TO() functions for multiple modules. Things like TO_DATE(), TO_CHAR(), TO_TIMESTAMP(), etc.
We then learned about the CAST() function which seems to have the same purpose but for a large amount of applications.
What's the difference between CAST() and the array of TO() functions?
To put it another way, when would I specifically want to use the former over the latter?
to_date, to_char, and to_timestamp are functions that exist in the Oracle database. convert is a function that exists in SQL Server. SQL Server doesn't have a to_date, to_char, or to_timestamp. Oracle doesn't have a convert*. Different databases will have different conversion functions.
cast is an ANSI standard function so it will basically exist everywhere. But it will generally be less flexible. You can't specify a format mask for example.
Technically, as #a_horse_with_no_name points out, Oracle does have a convert function. It just has nothing to do with converting data from one data type to another so it's completely unrelated to the SQL Server function.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
T-SQL Cast versus Convert
What is the differences between Cast and Convert functions in SQL Server with T-SQL?
Convert is a SQL server only function and Cast is more generic(can be used in other dbms). Convert provides more flexability than Cast. So if you are trying to choose which one to use, I would suggest Cast uness you have a specific reason to use Convert. As a suggestion;
Dates, times : Convert
Decimals, numerics : Cast
What is the general guidance on when you should use CAST versus CONVERT? Is there any performance issues related to choosing one versus the other? Is one closer to ANSI-SQL?
CONVERT is SQL Server specific, CAST is ANSI.
CONVERT is more flexible in that you can format dates etc. Other than that, they are pretty much the same. If you don't care about the extended features, use CAST.
EDIT:
As noted by #beruic and #C-F in the comments below, there is possible loss of precision when an implicit conversion is used (that is one where you use neither CAST nor CONVERT). For further information, see CAST and CONVERT and in particular this graphic: SQL Server Data Type Conversion Chart. With this extra information, the original advice still remains the same. Use CAST where possible.
Convert has a style parameter for date to string conversions.
http://msdn.microsoft.com/en-us/library/ms187928.aspx
To expand on the above answercopied by Shakti, I have actually been able to measure a performance difference between the two functions.
I was testing performance of variations of the solution to this question and found that the standard deviation and maximum runtimes were larger when using CAST.
*Times in milliseconds, rounded to nearest 1/300th of a second as per the precision of the DateTime type
CAST is standard SQL, but CONVERT is only for the dialect T-SQL. We have a small advantage for convert in the case of datetime.
With CAST, you indicate the expression and the target type; with CONVERT, there’s a third argument representing the style for the conversion, which is supported for some conversions, like between character strings and date and time values. For example, CONVERT(DATE, '1/2/2012', 101) converts the literal character string to DATE using style 101 representing the United States standard.
Something no one seems to have noted yet is readability. Having…
CONVERT(SomeType,
SomeReallyLongExpression
+ ThatMayEvenSpan
+ MultipleLines
)
…may be easier to understand than…
CAST(SomeReallyLongExpression
+ ThatMayEvenSpan
+ MultipleLines
AS SomeType
)
CAST uses ANSI standard. In case of portability, this will work on other platforms. CONVERT is specific to sql server. But is very strong function. You can specify different styles for dates
You should also not use CAST for getting the text of a hash algorithm. CAST(HASHBYTES('...') AS VARCHAR(32)) is not the same as CONVERT(VARCHAR(32), HASHBYTES('...'), 2). Without the last parameter, the result would be the same, but not a readable text. As far as I know, You cannot specify that last parameter in CAST.