If I type this into the expression box:
1=0 OR (1=1 AND 2=2)
It will change it when I save it and then when I open it again it comes out like this:
((1)=(0) OR (1)=(1) AND (2)=(2))
which reduces down to...
1=0 OR 1=1 AND 2=2
which is clearly different than my original expression. What gives?
Microsoft SQL Server Management Studio: 11.0.5058.0
AND is evaluated before OR, so both expressions would actually give the same result.
I imagine that is taken into account when the expression is processed and stored and so influences the resulting/stored expression.
Related
Can anybody tell me what does the error mean? Whenever I open the query builder it will prompt with an error indicating that SQL syntax errors were encountered.
https://msdn.microsoft.com/en-us/library/ms189012.aspx
I looked at the following page in MSDN but I don't understand what it means...
For instance, what do these bullet points from the MSDN article mean?
The SQL statement is incomplete or contains one or more syntax errors.
The SQL statement is valid but is not supported in the graphical panes (for example, a Union query).
The SQL statement is valid but contains syntax specific to the data connection you are using.
USER (which you've apparently decided is an appropriate table name) is a SQL Server reserved word.
The best solution is to rename your table, so you don't have to escape the table name every time you want to query it and to make it clear it's your user data (hey, there's a table name suggestion - userdata).
The other option is to escape the name by surrounding it with square brackets:
SELECT * FROM [users]
Note that it will get old fast having to do this with every query. Again, the best solution would be to rename the table to something that isn't a reserved word.
I'm using SQL Server 2012 and its Management Studio.
I am adding schemas in an existing database and there is a question I have regarding parameters. I noticed on a stored procedure page that the person has a parameter: #PersonID int,.
When I scroll down the page, so many times when he calls the parameter, he refers to it as #personid.
Does this actually make a difference in terms of functionality or performance or is it fine to keep it s it is?
The same applies to when calling a table. He has a table saved as 'Support.ErrorLog', but he calls it as below in his procedure:
insert into [support].[errorlog]...
TLDR; Case sensitiveness matters unless collation level is set as to ignore case sensitiveness. It does not matter in terms of functionality or performance.
If the code in question is working and in use, it seems that the database collation level is set to case insensitive.
You can verify this by running the following query
SELECT CONVERT (varchar, SERVERPROPERTY('collation'));
Like on my server instance for a particular DB the result was
SQL_Latin1_General_CP1_CI_AS
Here _CI_ means Case insensitive.
Had it been case sensitive the value would be something like
SQL_Latin1_General_CP1_CS_AS
You can read more about collation at this excellent MS knowledge base
I want to use the "split" function in a simple query on my SSRS 2008 report. However, I get an error "Query execution failed for dataset "SlsmRealNum". "Split" is not a recognized built-in function name". But it's listed as a common function (text) if I open up the Expression box on the query, so not sure why it's failing?
my simple select statement is:
select slsm_num, slsm_msid from Salesman where slsm_msid = split(User.UserID,"\").GetValue(1)
right now to get the report to work, I have one parameter (SlsmnNum) that has the Split expression in it (to get the MSID of the user) and then a 2nd parameter that uses the above query in the Dataset Salesrepum using the #SlsmnNum parameter as the MSID. I'd like to not have to have 2 parapmeters if possible and just get the actualy salesrep # in just one. Any help is greatly appreciated!
Your select statement is executed as SQL so the error you are getting is actually from SQL server. This may be where you are getting confused.
There are two components to SSRS - SQL Statements and Report Expressions. Typically, SQL statements are used to generate datasets by querying the database. Report expressions are used to organize, aggregate, and filter the dataset once obtained from the SQL database. Since the SQL statement is executed IN the SQL database, only the functions that are in the database are available. The code you posted is a SQL statement not a Report Expression.
For example, you can't take a Report Expression and expect it to work in SSMS? No, because they are two different entities with wholly different syntax and purpose. When it comes to using built-in SSRS functions inside a SQL statement it will not work, the database has no concept of what the built in User.UserId is and as such you must use a parameter to transport the value over to the SQL query. This is definition and purpose of a parameter and why they exist.
Split is a function in SSRS which is why you see it in your expression reference, however, it is not a function in SQL. The code you posted is SQL syntax, so I am betting that this is the SQL statement that you are using to obtain your dataset. Therefore the query fails since the SQL DB does not have a Split Function.
You can add this split function to your database and the code is located here: Split String in SQL. You could also use something along the following in your where clause, the following is your updated SQL statement.
SELECT slsm_num, slsm_msid from Salesman where slsm_msid = SUBSTRING(#UserId, PATINDEX('%\%', #UserId), LEN(#UserId))
You would set the #UserId parameter's value to an expression of User!UserID rather than specifying it in your select statement.
The SSRS expression examples have a function similar to what your code is trying to accomplish if you were wanting the same thing in the report side. The function you are looking for is InStr(). On your report side you could use something along the lines of:
=Parameters!User.Value.Substring(Parameters!User.Value.IndexOf("\")+1, Parameters!User.Value.Length-Parameters!User.Value.IndexOf("\")-1)
Expression examples can be found here: MSDN Expression examples.
Here is the deal.
I have 2 databases. One is older and has expanded data. The other is newer and has less relevant data. They both share the same products just one has more data.
I've begun a project where I want to expand the newer database to include some of the missing data that exists in the older one. Problem is the IDs don't match up between the databases. So I'm having to search by names. Which may or may not be the same case. The queries in visual studio are DEFINITELY case sensitive. I tested this and I am sure.
So my first thought was to do a like search with a lower function. Like this:
WHERE lower([Name1]) LIKE lower('%Name2%')
but when I went to run it it gave me an error. And visual studio automatically tried to change the syntax of the statement to this:
WHERE 'lower'([Name1]) LIKE 'lower'('%Name2%')
I could have sworn lower() was the right syntax. And I can't find anywhere on google saying any alternatives or why visual studio wouldn't like it. In fact I just tried a similar line in SQL Management Studio and it worked. Why is it not working in Visual Studio?
Use COLLATE to specify case sensitivity. Simply force a case insensitive collation, if needed. It may not be needed, depending on the existing collation of the data. Eg.:
SELECT ... FORM ...
WHERE Name1 COLLATE SQL_Latin1_General_CI LIKE '...';
First off VS does not execute the query, the collation on the column that you are querying will determine if SQL treats it as case sensitive or not. Also because you are using LIKE in your comparison what you actually want is something more like:
WHERE lower([Name1]) LIKE '%' + lower([Name2]) '%'
Use WHERE lower([Name1]) LIKE '%name2%' Since that value is constant (or input?) you don't need to convert it to lower here. You can do that beforehand.
Also, not sure about the [ ... ]. They shouldn't be needed either.
But I think the best option would be to tell the database that you want to compare case insensitive, like so:
I hand coded a simple SQL in SQL Server 2008 as below;
SELECT * FROM Tab1 WHERE
A='1' AND (B='1' OR C='1');
Being lazy I opened this query in the Query Editor to validate the syntax and pressed OK on the dialog without making any changes.
I noticed that the Query Editor had changed my query to:
SELECT * FROM Tab1 WHERE A='1' AND (B='1') OR (C='1');
clearly this changes the logic of the SQL and returns different results depending on which one you execute.
I routinely use the Query Editor to validate my syntax on complex queries. So a little worried that the a subtle change like this would go unotice, but would change the outcome.
Is this a feature of the designer? Is there something I can do to change this behavior?
EDIT: Thanks for pointing out that the changes made by the editor is not quite the same as above, but still the query is modified although the results are the same.
Thanks
I tried to replicate this in the Query Designer and had a slightly different result. I typed the same as you:
SELECT * FROM Tab1 WHERE A='1' AND (B='1' OR C='1');
And got this:
SELECT *
FROM Tab1
WHERE (A = '1') AND (B = '1') OR
(A = '1') AND (C = '1')
I have to say that the result is the same, but we can all see a dangerous road here. Also, I did not like the (A = '1') replication. Heck, I want the code how I coded it!
A word to the wise: I never format my queries in SQL Server Management Studio. Have you seen what it does to your view's code? I hate it. I just code somewhere else and paste in SMS when done.
The statement
SELECT * FROM Tab1 WHERE A='1' AND (B='1' OR C='1')
resolves for me to:
SELECT * FROM Tab1 WHERE (A='1') AND (B='1') OR (A='1') AND (C='1')
This is surprisingly correct, as in SQL Server TSQL the AND operator has precedence over OR. That means the above is the same like the following, because the AND-operator gets evaluated before the OR-operator:
SELECT * FROM Tab1 WHERE ((A='1') AND (B='1')) OR ((A='1') AND (C='1'))
And this is the same like the initial statement being used in the question.
See Operator Precedence (Transact-SQL) for details.