It may just be me, but... Despite the fact that most sql developers may consider cast & convert to be very basic stuff, and that may be true, I find Microsoft's documentation page on CAST & CONVERT to be one of the most hideous, not-intuitively-laid-out, hard to understand things I have ever seen. Much of their documentation is great. Like constantly trying to blend the entire page into a mix of both cast and convert, jumping back and forth in each sentence... rather than dealing with them separately. And who puts the target_type as the first argument? Putting the expression as the first argument would be more intuitive - and follow the other 99% of numerous programming languages' syntax. UH
MS says that I can only convert to 3 data types: (well actually I'm not really sure if this applies to both CAST and CONVERT, since they ARE, in fact, different... But according to the layout of that webpage, it apparently applies equally to both - even though I already know for a fact that it is not true for CAST, which I use much more frequently).
It says: "Is the target data type. This includes xml, bigint, and sql_variant"
Putting aside for the moment the fact that I CAST things as many other datatypes all the time (date, varchar),
My immediate question is: if I can only CONVERT to those data types, then why does this work?
select CONVERT(varchar(200), cast(50 as smallint))
And finally, I'd like to run an INSERT that will be getting a smallint and putting it into a varchar(200) column.
All I'm trying to do is avoid any failures, so maybe I don't really "need" to convert or cast over to varchar, but any commments on
answer on what is my apparent misunderstanding about the CONVERT documentation
or
how to safely convert it to insert to varchar
are welcome. As long as you're not just overly unpleasant, since there are always those MS fans who get hot under the collar at all critiques of MS .. :|
Yes, you can convert from smallint to varchar.
1) answer on what is my apparent misunderstanding about the CONVERT
documentation
This may be product of general lack of understanding on what data types are, how can they be converted from one type to another and equally important; what styles are when it comes to the aesthetic representation of a data type.
CAST is an explicit cast operation with no style options.
CONVERT is also an explicit cast that gives you the ability to specify a style for the output.
The documentation clearly states:
Implicit Conversions
Implicit conversions are those conversions that occur without
specifying either the CAST or CONVERT function. Explicit conversions
are those conversions that require the CAST or CONVERT function to be
specified. The following illustration shows all explicit and implicit
data type conversions that are allowed for SQL Server system-supplied
data types. These include xml, bigint, and sql_variant. There is no
implicit conversion on assignment from the sql_variant data type, but
there is implicit conversion to sql_variant.
For your second question
2) how to safely convert it to insert to varchar
Depending of what you mean by safe. Converting to varchar is the convertion that most likely succeed. But whenever to cast to any toher datatype you are intrinsically changing the very nature of the data and will lose precision when casting to smaller types (or applying styles).
The documentation clearly states:
Truncating and Rounding Results
When you convert character or binary expressions (char, nchar,
nvarchar, varchar, binary, or varbinary) to an expression of a
different data type, data can be truncated, only partially displayed,
or an error is returned because the result is too short to display.
Conversions to char, varchar, nchar, nvarchar, binary, and varbinary
are truncated, except for the conversions shown in the following
table.
in other words, casting is never safe.
Numbers always get silently truncated for me. I would propose:
Option 1
Compare the converted value with the original value.
DECLARE #ORIGINAL DECIMAL(13,2) = -99999999999.99 --
DECLARE #EXPECTED VARCHAR(15) = ''
SELECT #EXPECTED = CONVERT(VARCHAR(15),#ORIGINAL)
IF CONVERT(DECIMAL(13,2),#EXPECTED) != #ORIGINAL SELECT 'Ooops'
Option 2
Make sure that all possible values will fit in target varchar.
Decimal(13,2). Widest number possible will be "-99999999999.99" needs varchar(15):
13 chars for digits
1 char for decimal separator
1 char for minus sign
Smallint stores 2 bytes, from "-32768" to "32767", needs varchar(6):
- 5 chars for digits
- 1 char for minus sign
Not sure if you need chars for thousands separators, or if you can change it via settings.
I am currently working with some ErlangC calculations to determine occupancy rates. I've got the functions I need working but when I start getting into higher numbers such as POWER(145,145), ~2.50242070x10^313, I get the following:
Arithmetic overflow error converting expression to data type float.
Is there anything in MsSQL I can use to handle these larger numbers? MS Excel can, but MsSQL can't?
This is really hard. Not even Excel can handle this number. Excel can handle until 145^142 = 8.2084E+306. If you try 145^143 you will get an error.
CLR data types also do not handle this number, so CLR Data Type is not an option.
As ErlangC calculations are done for traffic modeling, I would review your process to see if you are using the correct units on your formula (minutes, seconds, etc). This number is really really big to be achieved in a Call Center if this is your case.
This question already has answers here:
Functions vs procedures in Oracle
(7 answers)
Closed 7 years ago.
I would like to know about difference between stored procedure and function in oracle.As a fresher to oracle,can you all help me to know the differences?
A function generally returns a single value in Oracle (be it a scalar value, or a single defined object/data-table). A procedure on the other hand can return any number of outputs and does not need to actually have any inputs OR any outputs.
If you need to do JOIN-like behaviour then you'll need to use a function to apply the function against individual rows with varying input. Oracle functions are semantically more graceful than functions - but are harder to optimise and see inside of sometimes.
I want to compare datetime in C. I googled but I didn't get any proper solution. I am having datetime in string format i.e date1 = "2014-02-13 12:22:21" and date2 = "2014-02-10 12:22:21".
Now, I want comparison b/w date1 and date2.
Please suggest me proper solution.
Just use strcmp. It works because with this particular date/time format, the lexicographical order is the same as the chronological order.
If you don't run this on the critical path, Then just use strncmp(). Else, if speed is important, parse it with strptime()+mktime() into UTC uint64_t microseconds/milliseconds since epoch and compare those. I would also make sure timezones are taken into account consistently across the code base.
To clarify the point raised in the comment - whether to prefer string comparison to timestamp comparison (paying parsing overhead) is solely determined by the usage pattern and can be benchmarked in a simple synthetic test.
Both of the following queries will give me the same result, and I've seen both techniques being used in the past to ensure a decimal data type is returned.
select CAST(5 as decimal(18,2))/2
select 5*1.0/2
Which method is best to use?
Why would people use *1.0 over casting? Is this just because its quicker to type?
If you want to control the precision or scale of the result, then you'll have to use CAST or CONVERT. But I believe that if you just want "a decimal", then as you suggested, it's just quicker to type * 1.0.