Lower() In Visual Studio 2010 SQL Query Not Working. Alternatives? - sql

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:

Related

Does parameters have to match case

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

Use a checkmark as an column alias in SQL Server 2008 R2

I have a requirement to do something I believe should be simple enough, but am not finding the right answer to. How do I use a checkmark as a column alias in SQL Server 2008 R2?
I've tried using Char(251) by setting it to a value and trying to assign the value as the column alias, but no joy on that one.
I've tried using Char(251) (and I know that's more of a square root mark, but not sure of the checkmark ascii value if there is one. I believe that is a unicode value?) directly but again no joy. This should be simple, but I'm simply not finding it.
Thanks.
You cannot use expressions as identifiers in SQL Server (or any other SQL database for that matter). You can, however, use Unicode characters in identifiers, so simply copy and paste the desired character:
select 'yes' as "☑︎";
or even
select 'blah' as "😀";
Having said that, you should not be doing all that -- presentation is not the task for a database engine; it should be implemented in the client application.

Renaming a column without breaking the scripts and stored procedures

I want to modify a column name to new name present in a table
but here problem i want to manually modify the column name present in Triggers or SP's.
Is there a any better way of doing it.
To rename a column am using this
sp_RENAME 'Tablename.old_Column', 'new_column' , 'COLUMN';
similarly how can i do it for triggers or SP's.? without opening each script?
Well, there are a bunch of 3rd party tools that are promising this type of "safe rename", some for free and some are not:
ApexSQL has a free tool for that, as MWillemse wrote in his answer,
RedGate have a commercial tool called SQLPrompt that also have a safe renaming feture, However it is far from being free.
Microsoft have a visual studio add-in called SQL Server Data Tools (or SSDT in the short version), as Dan Guzman wrote in his comment.
I have to say I've never tried any of these specific tools for that specific task, but I do have some experience with SSDT and some of RedGate's products and I consider them to be very good tools. I know nothing about ApexSQL.
Another option is to try and write the sql script yourself, However there are a couple of things to take into consideration before you start:
Can your table be accessed directly from outside the sql server? I mean, is it possible that some software is executing sql statement directly on that table? If so, you might break it when you rename that column, and no sql tool will help in this situation.
Are your sql scripting skills really that good? I consider myself to be fairly experienced with sql server, but I think writing a script like that is beyond my skills. Not that it's impossible for me, but it will probably take too much time and effort for something I can get for free.
Should you decide to write it yourself, there are a few articles that might help you in that task:
First, Microsoft official documentation of sys.sql_expression_dependencies.
Second, an article called Different Ways to Find SQL Server Object Dependencies that is written by a 13 years experience DBA,
and last but not least, a related question on StackExchange's Database Administrator's website.
You could, of course, go with the safe way Gordon Linoff suggested in his comment, or use synonyms like destination-data suggested in his answer, but then you will have to manually modify all of the columns dependencies manually, and from what I understand, that is what you want to avoid.
Renaming the Table column
Deleting the Table column
Alter Table Keys
Best way use Database Projects in Visual Studio.
Refer this links
link 1
link 2
you can do what #GorDon suggested.
Apart from this,you can also play with this query,
select o.name, sc.* from sys.syscomments sc inner join sys.objects o
on sc.id=o.object_id where sc.text like '%oldcolumnname%'
this will return list of all proc and trigger.Also you can modify filter to get exact list.then it will be very easy for you to modify,manually.
But whatever you decide,don't simply drop old column.
To be safe,even keep back up.
This suggestion relates to Oracle DB, however there may be equivalent solutions in other DBMS's.
A temporary solution to your issue is to create a pseudocolumn. This solution looks a little hacky because the syntax for a pseudocolumn requires an expression. The simplest expression I can think of is the case statement below. Let me know if you can make it more simple.
ALTER TABLE <<tablename>> ADD (
<<new_column_name>> AS (
CASE
WHEN 1=1 THEN <<tablename>>.<<old_column_name>>
END)
);
This strategy basically creates a new column on the fly by evaluating the case statement and copying the value of <<old_column_value>> to <<new_column_value>>. Because you are dynamically interpolating this column there is a performance penalty vs just selecting the original column.
The one gotcha is that this will only work if you are duplicating a column once. Multiple pseudocolumns cannot contain duplicate expressions in Oracle.
The other strategy you can consider is to create a view and you can name the columns whatever you want. You can even INSERT/UPDATE/DELETE (execute DML) against views, but this would give you a whole new table_name, not just a new column. You could however rename the old table, and name your view the same as your old table. This also has a performance penalty vs just accessing the underlying table.
You might want to replace that text in definition. However, you will be needing a dedicated administrator connection in sql server. Versions also vary in setting up a dedicated administrator connection. Setting up the startup parameter by adding ;-T7806 under advanced. And by adding Admin: before the servername upon logging in. By then, you may be able to modify the value of the definition.

SQL Left/Deliminated Character

Pretty simple one today. I've got a column, let's call it title, with a bunch of project titles. What I need to to pull everything from the left of the ":" and do a left/right trim (I'm then going to be using that in a join later on but I just need a column with the new data for now). So here's an example of what the current column looks like:
And here's what I need it to look like after the query is run:
The problem is while the # are 6 characters now, I can't guarantee they'll always be 6 characters. So if I was doing this in Excel I'd use the deliminated feature or just write a left/len/search function. Wondering how to do the same in SQL. BTW, I'm using SQL Server Management Studio.
Thoughts?
Assuming that your number is always followed by a [space]:[space], then simply look for that first space, and use its location as the argument for a left-substring operation:
SELECT LEFT(Title, CHARINDEX(' ', Title, 0)) AS "New Title"
p.s. Just say you're using MS SQL Server. SSMS is just a management front-end for that database.
check this post out. it does exactly what you are trying to do.
SQL Server replace, remove all after certain character

Can you explain this SQL injection?

The website i worked was recently attempted to be hacked by the following SQL injection script
boys' and 3=8 union
select 1,
concat(0x232425,ifnull(`table_name`,0x30),char(9),ifnull(`table_rows`,0x30), char(9),0x252423),
3,4,5,6,7,8,9
from `information_schema`.`tables`
where table_schema=0x62646B3032 limit 44,1 -- And '8'='8
This injection returned the mysql table name. This was reported by the error reporting system on that website and we managed to fix that part however I am not able to understand what does the above injection mean?
Anyone can explain this?
Penuel
They're using a select from the Information Schema views in mysql server :
http://dev.mysql.com/doc/refman/5.0/en/information-schema.html
They use some clever hacks to rout out simple sql injection prevention techniques.
According to this the MySQL concat()
Returns the string that results from
concatenating the arguments. May have
one or more arguments. If all
arguments are nonbinary strings, the
result is a nonbinary string. If the
arguments include any binary strings,
the result is a binary string. A
numeric argument is converted to its
equivalent binary string form
So 0x232425 is converted to #$% which is simply added to the begining and end of the table_name field. Maybe just to make it easier for them to pull out the Table names later using Regex.
Later on the char(9) is equivalent to a tab as you can see here and is just there to format the output nicer.
The 3,4,5,6,7,8,9 is just there so that the columns match the boys table that they are performing the Union on.
This injection returned the mysql table name.
Do you mean that your website displayed the table name when you gave it this input, or that the query returns that when run from the mysql client? If it showed on your website, then the attacker has the ability to inject much more harmful queries. Check your data.