I found something like this in a SqlServer DB stored proc:
SELECT stuff
FROM mytable
WHERE mytable.column = + #parameter
It seems to run without error, so I assume it's okay. What would the "+" be doing?
(Not surprisingly, this is a difficult topic to effectively search on, so I apologize in advance if this is a duplicate.)
+ is the opposite of - which changes sign.
It does nothing.
Unary + doesn't do anything in T-SQL.
Perhaps the person who wrote it saw 0+#parameter and deleted the 0 to "optimize it". 0+#parameter generates an error if #parameter isn't numeric, whereas unary + doesn't do anything.
What type is #parameter? This probably just a unary plus, (as opposed to minus). For numeric types this has no effect.
Returns the data type of
numeric_expression, except that an
unsigned tinyint expression is
promoted to a smallint result.
Positive unary operator
It looks like it is a short hand notation for converting the parameter into a numeric type. Depending on your database server, it might not even be needed.
Related
I'm fairly new to Visual Basic (my background is mostly C#) so I only recently found out that ++i is not the same thing as i+=1 in VB.NET. However, my VB.NET code still compiles when I pass ++i as a parameter, even though it doesn't increment the variable:
++i 'doesn't compile
i++ 'doesn't compile
Foobar(i++) 'doesn't compile
Foobar(++i) 'compiles, but doesn't increment i
The fact that the last statement above doesn't cause an error leads me to wonder if ++ actually does mean something in VB.NET, just not what I thought it meant at first. If it doesn't, is there some other reason it isn't causing an error?
It is just the unary version of the + operator (see docs) applied twice.
Foobar(++i)
Foobar(+(+i))
Foobar(+(+(i)))
' These are all the same
For numerical values, the unary + (i.e. the + operator without second operand) does nothing:
If expression2 is absent, the + operator is the unary identity operator for the unchanged value of an expression.
However, it is not entirely clear from the docs what it will do to non-numeric values. The docs explain various cases with two operands, which all don't seem to apply here.
There is even one sentence that sounds like it could be applied, but it does not do what it says if used with unary +:
If either Object expression evaluates to Nothing or DBNull, the + operator treats it as a String with a value of "".
So you would expect that +Nothing gives "" as well, but it gives 0 instead. In fact, it appears that the unary + converts non-numerical types to Double, including strings for which + would otherwise mean concatenation (for example +"1.234" gives 1.234, and +"Hello" gives an error that this string cannot be converted to Double - and with Option Strict On, you can't convert any string implicitly anyway). It seems to behave more like a binary + with 0.0 as first operand.
You can also overload the unary + separately from the binary + and give it a different meaning entirely*. (Or do the opposite - make it do nothing even on a non-numeric type, such as what TimeSpan does - it returns the original timespan again when unary + is applied on it, and not a Double.)
*: Which probably is not such a good idea though. When overloading an operator, the meaning of it should always be intuitive.
There is no ++ operator in VB. The + unary operator is just like the - unary operator applied to a number. Numbers are positive by default but, just as you can explicitly make a number negative by prefixing it with a - operator, you can make it explicitly positive by prefixing it with a + operator. You can use as many + operators as you like. Similarly, you can use as many - operators as you like. The difference is that + operators don't change the value where - operators do.
In C-based languages, assignments actually return a value where they don't in VB. In C#, you can do this:
i += 1
and it will get the value of i, add 1 to it, assign the result back to i and then return that result, so you can use that expression where a value is expected. In VB, it does all the same things up to the assignment but it does not return a value, so you cannot use that expression where a value is expected.
In C-based languages, where you place the ++ operator makes a difference. The expression:
++i
increments i and returns the final value, whereas this expression:
i++
increments i and returns the original value. That's why some argue that the C++ language should actually be named ++C.
I've found this strange behaviour and I searched but couldn't find anything about it.
I know that in my example I don't need to cast [affairenum] to STRING, but because of a specific syntax in Entity Framework this is how an Affairenum.Contains(), StartsWith() or EndsWith() ends up being generated.
Consider for example a table that contains an id (affaireid column) and numbers (affairenum column) with values from 1 to 5000000.
SELECT TOP (1000) [affaireid]
,[affairenum]
,STR(affairenum) AS string
FROM [dbo].[ULAffaire]
where STR(affairenum) LIKE N'%9'
Works and returns results. Same goes with N'%9%'.
SELECT TOP (1000) [affaireid]
,[affairenum]
,STR(affairenum) AS string
FROM [Ulysse].[dbo].[ULAffaire]
where STR(affairenum) LIKE N'9%'
Does not work and returns nothing. The difference here being LIKE N'9%', the equivalent of a StartsWith().
STR(affairenum) looks identical to affairenum, EndsWith() and Contains() both work normally, but this returns nothing.
I've tried with LOWER(), to no avail. Is the STR() method adding anything ? a space, some weird character ? Am I missing something silly ?
That is because str() left pads the results with spaces. The default is a length of 10 (see here).
I'm not a fan of using numbers as strings. But if you do so, explicit conversion should do what you want:
where cast(affairnum as varchar(255)) like '9%'
That is, str() is not a type conversion function. It is a string formatting function -- hence the presence of spaces where you might not expect them.
I should note that you don't even need to explicit convert the number to a string, so this works:
where affairnum like '9%'
However, I have such bad memories of hours and hours devoted to fixing problems in SQL code that used implicit conversion, so I cannot in good conscience propose implicit conversion to someone else.
So, I'm writing a language using flex/bison and I'm having difficulty with implementing identifiers, specifically when it comes to knowing when you're looking at an assignment or a reference,
for example:
1) A = 1+2
2) B + C (where B and C have already been assigned values)
Example one I can work out by returning an ID token from flex to bison, and just following a grammar that recognizes that 1+2 is an integer expression, putting A into the symbol table, and setting its value.
examples two and three are more difficult for me because: after going through my lexer, what's being returned in ex.2 to bison is "ID PLUS ID" -> I have a grammar that recognizes arithmetic expressions for numerical values, like INT PLUS INT (which would produce an INT), or DOUBLE MINUS INT (which would produce a DOUBLE). if I have "ID PLUS ID", how do I know what type the return value is?
Here's the best idea that I've come up with so far: When tokenizing, every time an ID comes up, I search for its value and type in the symbol table and switch out the ID token with its respective information; for example: while tokenizing, I come across B, which has a regex that matches it as being an ID. I look in my symbol table and see that it has a value of 51.2 and is a DOUBLE. So instead of returning ID, with a value of B to bison, I'm returning DOUBLE with a value of 51.2
I have two different solutions that contradict each other. Here's why: if I want to assign a value to an ID, I would say to my compiler A = 5. In this situation, if I'm using my previously described solution, What I'm going to get after everything is tokenized might be, INT ASGN INT, or STRING ASGN INT, etc... So, in this case, I would use the former solution, as opposed to the latter.
My question would be: what kind of logical device do I use to help my compiler know which solution to use?
NOTE: I didn't think it necessary to post source code to describe my conundrum, but I will if anyone could use it effectively as a reference to help me understand their input on this topic.
Thank you.
The usual way is to have a yacc/bison rule like:
expr: ID { $$ = lookupId($1); }
where the the lookupId function looks up a symbol in the symbol table and returns its type and value (or type and storage location if you're writing a compiler rather than a strict interpreter). Then, your other expr rules don't need to care whether their operands come from constants or symbols or other expressions:
expr: expr '+' expr { $$ = DoAddition($1, $3); }
The function DoAddition takes the types and values (or locations) for its two operands and either adds them, producing a result, or produces code to do the addition at run time.
If possible redesign your language so that the situation is unambiguous. This is why even Javascript has var.
Otherwise you're going to need to disambiguate via semantic rules, for example that the first use of an identifier is its declaration. I don't see what the problem is with your case (2): just generate the appropriate code. If B and C haven't been used yet, a value-reading use like this should be illegal, but that involves you in control flow analysis if taken to the Nth degree of accuracy, so you might prefer to assume initial values of zero.
In any case you can see that it's fundamentally a language design problem rather than a coding problem.
Recently I was working with ISNUMERIC in SQL Server, when I encountered a problem, which led to finding this snippet of code.
SELECT ISNUMERIC('.')
This returns 1, as in true, shouldn't this return 0 as in false?
See IsNumeric() Broken? Only up to a point.
SELECT CAST('.' AS MONEY)
returns 0.00 (though the cast fails for int and float)
ISNUMERIC just checks that the value can be cast to any one of the numeric datatypes which is generally useless. Usually you want to know whether it can be cast to a specific type.
Additionally it doesn't even seem to do that task correctly for all possible inputs.. ISNUMERIC(' ') returns 0 despite casting successfully to both int and money. Conversely ISNUMERIC(N'８') returns 1 but does not cast successfully to anything that I tried.
Some useful helper functions for that are here IsNumeric, IsInt, IsNumber.
SQL Server 2012 introduced TRY_PARSE and TRY_CONVERT that help with this greatly.
Because "." is used in a decimal number !
see here
isnumeric for '-' & '.' Why isnumeric('-') & isnumeric('.') returning
1?
Answer: Because "-" means negative and "." is used in a decimal
number. I have no clue why they named it ISNUMERIC though. They
should have named it, ISNUMBERRELATED.
I think it also interprets a number of other non-numeric fields as numeric, there's further info here -
http://classicasp.aspfaq.com/general/what-is-wrong-with-isnumeric.html
SQL is detecting that the following string ISNUMERIC:
'07213E71'
I believe this is because the 'E' is being classed as a mathmatical symbol.
However, I need to ensure that only values which are whole integers are returned as True.
How can I do this?
07213E71 is a floating number 7213 with 71 zeros
You can use this ISNUMERIC(myValue + '.0e0') to test for whole integers. Slightly cryptic but works.
Another test is the double negative myValue NOT LIKE '%[^0-9]%' which allows only digits 0 to 9.
ISNUMERIC has other issues in that these all return 1: +, -,
To nitpick: This is a whole integer. It is equivalent to 7213 * 10 ^ 71.
In the documentation it says
ISNUMERIC returns 1 when the input expression evaluates to a valid integer, floating point number, money or decimal type; otherwise it returns 0. A return value of 1 guarantees that expression can be converted to one of these numeric types.
Your number is also float (with exponential notation), therefore the only way to have ISINTEGER is to define it yourself on SQL. Read the following link.
http://classicasp.aspfaq.com/general/what-is-wrong-with-isnumeric.html
Extras:
http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=59049
http://www.tek-tips.com/faqs.cfm?fid=6423
I have encountered the same problem. IsNumeric accepts "$, €, +, -, etc" as valid inputs and Convert function throws errors because of this.
Using "LIKE" SQL statement fixed my problem. I hope it'll help the others
SELECT UnitCode, UnitGUID, Convert(int, UnitCode) AS IntUnitCode
FROM [NG_Data].[NG].[T_GLB_Unit]
WHERE ISNULL(UnitType,'') <>'Department'
AND UnitCode NOT LIKE '%[^0-9]%'
ORDER BY IntUnitCode
PS: don't blame me for using "UnitCode" as nvarchar :) It is an old project :)
You have to ensure it out of the call to the database, whatever the language you work with, and then pass the value to the query. Probably the SQL is understanding that value as a string.