According to https://technet.microsoft.com/en-us/library/dd255271(v=sql.110).aspx:
\ Divides two numbers and returns an integer result.
However, I cannot figure out how to use it. All my attempts end up the same - the error
Incorrect syntax near '\ 5'
when trying to do an integer division by 5.
So how do we use the damn thing?
The link that you posted is specific to SSRS (SQL Server Reporting Services). You can use \operator in Reporting Services expressions, which is not the same as T-SQL.
T-SQL does not support \ operator, only / operator. You can see the list of valid arithmetic operators on MSDN
If you are confused about what is Expression and what is T-SQL, expression is basically statement that you use in report, often to process or format the data. T-SQL on the other hand is the language which is used to execute queries and commands on SQL databases.
Do you mean this?
http://sqlfiddle.com/#!3/1d3dd/1
You can divide like this
select 4/2
This will give you 2
If you are looking for to divide and get if any remainder then is %
See an example here http://sqlfiddle.com/#!3/1d3dd/4
Related
In my sql server 2017 standard CU 20 there is a very often excuted query that has this awful condition:
AND F.progressive_invoice % #numberofservicesInstalled = #idService
Is there a mathematical way to put it in a more convenient way for sql server?
The query lasts from 240 to 500 ms
Can you help me to do better? Please
What do you think is particularly awful here?
Is this query performing badly? Are you sure, that this condition is responsible?
This % is the modulo operator.
SELECT 13 % 5 => Remainder is 3
--This is roughly the same your code is doing:
DECLARE #Divisor INT=5; --Switch this value
DECLARE #CompareRemainder INT=3;
SELECT CASE WHEN 13 % #Divisor = #CompareRemainder THEN 'Remainder matches variable' ELSE 'no match' END;
Your line of code will tell the engine to compute a integer division of F.progressive_invoice and the variable #numberofservicesInstalled, then pick the remainder. This computation's result is compared to the variable #idService.
As this computation must be done for each value, an index will not help here...
I do not think, that this can be put more sargable.
UPDATE
In a comment you suggest, that it might help to change the code behind the equal operator. No this will not help.
I tried to think of a senseful meaning of this... Is the number of a service (or - as the variable suggests - its id) somehow hidden in the invoice number?
execution plan and row estimation:
The engine will see, that this must be computed for all rows. It would help to enforce any other filter before you have to do this. But you do not show enough. The line of code we see is just one part of a condition...
Indexes and statistics will surely play their roles too...
The short answer to your direct question is no. You cannot rearrange this expression to make it a sargable predicate. At least, not with a construct which is finite and agnostic of the possible values of #numberofservicesinstalled.
How can we get a rational number in a VALUES clause in Snowflake ?
SELECT * FROM (
VALUES (1/3.0), (2)
) AS t ;
returns :
SQL compilation error: Invalid expression [1 / 3] in VALUES clause
This is so peculiar it could be characterised as a bug.
Any division that results in a whole number works, but fractions trigger the error message.
The Documentation states that:
Each expression must be a constant, or an expression that can be evaluated as a constant during compilation of the SQL statement.
Most simple arithmetic expressions and string functions can be evaluated at compile time, but most other expressions cannot.
Clearly (1/3) should be such a simple arithmetic expression. The simple workaround is of course to calculate the answer and include as a decimal number:
SELECT * FROM (VALUES (0.33333333333333333), (2)) AS T(VAL);
On second thought this is not as straight forward as it seems. If those values are used in a CREATE TABLE AS SELECT statement, should the data type be NUMBER(7,6) or FLOAT or something else? Maybe it is best to be specific in these cases.
The specifics for division etc are documented in Scale and Precision in Arithmetic Operations.
if you know you have a large number of rational input you want you can just do the math in the select
SELECT column1/column2 FROM VALUES (1,3),(2,1);
giving:
COLUMN1/COLUMN2
0.333333
2.000000
I am surprised! This statement below is valid in SQL SERVER:
SELECT +'ABCDEF'
Has SQL Server defined + as a Unary operator for string types?
Here is my own answer to this question (Please also see the update at the end):
No, there isn't such unary operator defined on the String expressions. It is possible that this is a bug.
Explanation:
The given statement is valid and it generates the below result:
(No column name)
----------------
ABCDEF
(1 row(s) affected)
which is equivalent to doing the SELECT statement without using the + sign:
SELECT 'ABCDEF'
Being compiled without giving any errors, in fact being executed successfully, gives the impression that + is operating as a Unary operation on the given string. However, in the official T-SQL documentation, there is no mentioning of such an operator. In fact, in the section entitled "String Operators", + appears in two String operations which are + (String Concatenation) and += (String Concatenation); but neither is a Unary operation. Also, in the section entitled "Unary Operators", three operators have been introduced, only one of them being the + (Positive) operator. However, for this only one that seems to be relevant, it soon becomes clear that this operator, too, has nothing to do with non-numeric string values as the explanation for + (Positive) operator explicitly states that this operator is applicable only for numeric values: "Returns the value of a numeric expression (a unary operator)".
Perhaps, this operator is there to successfully accept those string values that are successfully evaluated as numbers such as the one that has been used here:
SELECT +'12345'+1
When the above statement is executed, it generates a number in the output which is the sum of both the given string evaluated as a number and the numberic value added to it, which is 1 here but it could obviously be any other amount:
(No column name)
----------------
12346
(1 row(s) affected)
However, I doubt this explanation is the correct as it raises to below questions:
Firstly, if we accept that this explanation is true, then we can conclude that expressions such +'12345' are evaluated to numbers. If so, then why is it that these numbers can appear in the string related functions such as DATALENGTH, LEN, etc. You could see a statement such as this:
SELECT DATALENGTH(+'12345')
is quite valid and it results the below:
(No column name)
----------------
5
(1 row(s) affected)
which means +'12345' is being evaluated as a string not a number. How this can be explained?
Secondly, while similar statements with - operator, such as this:
`SELECT -'ABCDE'`
or even this:
`SELECT -'12345'`
generate the below error:
Invalid operator for data type. Operator equals minus, type equals varchar.
Why, shouldn't it generate an error for similar cases when + operator has been wrongly used with a non-numeric string value?
So, these two questions prevent me from accepting the explanation that this is the same + (unary) operator that has been introduced in the documentation for numeric values. As there is no other mentioning of it anywhere else, it could be that it is deliberately added to the language. May be a bug.
The problem looks to be more severe when we see no error is generated for statements such as this one either:
SELECT ++++++++'ABCDE'
I do not know if there are any other programming languages out there which accept these sort of statements. But if there are, it would be nice to know for what purpose(s) they use a + (unary) operator applied to a string. I cannot imagine any usage!
UPDATE
Here it says this has been a bug in earlier versions but it won't be fixed because of backward compatibility:
After some investigation, this behavior is by design since + is an unary operator. So the parser accepts "+ , and the '+' is simply ignored in this case.
Changing this behavior has lot of backward compatibility implications so we don't intend to change it & the fix will introduce unnecessary changes for application code.
Lets say i have a binary field checked
Lets also assume that 3 documents out of 10 has checked:1 others checked:0
When I search in lucene
checked:1 - returns correct result (3)
checked:0 - returns correct result (7)
-checked:1 - returns correct result (7)
-checked:0 - returns correct result (3)
BUT
-(-(checked:1)) - suddenly returns wrong result (10, i.e. entire data set).
Any idea why lucene query parse acts so weird
Each Lucene query has to contain at least one positive term (either MUST/+ or SHOULD) so it matches at least one document. So your queries -checked:1 and -checked:0 are invalid, and I am surprised you are getting any results.
These queries should (most likely) look like this:
+*:* -checked:1
+*:* -checked:0
Getting back to your problem: double negation makes no sense in Lucene. Why would you have double negation, what are you trying to query?
Generally speaking, don't look at Lucene query operators (! & |) as Boolean operators, they aren't exactly what you think they are.
After some research and trial and error and building up on answer from midas, I have came up with the method to resolve this inconsistency. When I say inconsistency, I mean from a common sense view for a user. From information retrieval prospective, midas has linked an interesting article, which explains why such a query makes no sense.
So, the trick is to keep each negative expression with MatchAllDocsQueryNode class, namely the rewritten query has to look like this:
-(-(checked:1 *:*) *:*)
Then the query will produce the expected result. I have accomplished it by writing my own nodeprocessor class, which performs necessary operations.
I am stuck on trying to find the meaning of a plus sign in a where clause. Anyone have any ideas on this one? Been stuck for a bit on it. The query itself is pretty simple and work similarly with, or with without the plus sign. I'd like to remove it unless it's there for a reason.
SELECT userID from tblUser WHERE + userName = SYSTEM_USER
Added note: This is in SQL Server 2008 not Oracle, nor did it come from and Oracle migration... As mentioned below there is an older join notation for Oracle that uses the + generally postfixed to some of the criteria.
The unary + operator is simply a no op. This is explained in the documentation for this operator, which is here:
Although a unary plus can appear before any numeric expression, it
performs no operation on the value returned from the expression.
Specifically, it will not return the positive value of a negative
expression. To return positive value of a negative expression, use the
ABS function.
I actually believe this remark is a wee little bit misleading. I think the unary plus operator will convert a string argument to a number. When applied to a constant string filled with digits, this could actually be beneficial as a way of encouraging the compiler to use an index on a numeric field.
It looks like the plus operator in the where clause is used for left or right outer joins.
You don't need it in your case, but you can read up on them here.
The reason your query works the same either way is because data is only coming from a single table. The join is superfluous.
A quick search also lead me to this answer, which states using the + method for joins is not recommended.
Update
Since you're using Microsoft SQL Server 2008, this is my best guess:
The '+' operator is used for string concatenation.