I am using mssql database with sequelize for my node.js application. I want only the exact match of my query string.but I am getting the same strings with different cases also.
For example, I want to fetch the record where some column = 'work'. But if I give 'WoRK' or something like that it should not return anything. But it matches with the 'work' in the database.
How can I change that?
Can anyone help me out?
SQL Server's string comparisons are by default case-insensitive (unless the table column is defined with a proper collation).
You can do this in the query by setting a collation for the equality - for example:
where some_column = 'work' collate Latin1_General_CS_AS
Related
I don't know how to explain but I'll try, into my database in a table, I have one record with many fields.
The username field, for example, contains the value = 'any-user-test' but if I execute a "SELECT" clause and in the WHERE section I compare username='any-user-test' the result does not contain the record.
But if I compare using username LIKE '%any-user-test' the record is returned.
And as further proof using:
WHERE CONVERT(username USING ASCII) = 'any-user-test'
the record is returned too.
The database is MariaDB in a server Ubuntu using encryption and CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci.
Any idea how to identify the problem?
I am trying to load a web log data into my SQL Server database. One of my column contains an url link, for example
http://stackoverflow.com/questions/ask?title=why%
I need to load rows contain "questions" string in the url column only.
In my SSIS package, I use conditional split with condition:
FINDSTRING(url, "questions", 1) >= 1.
I got 500 rows.
However, when I try to confirm it in the database with the following condition:
where url like '%questions%'
I got 530 rows.
I though this two conditions are equivalent and should return same number of rows. Can anyone help me point out what are the difference between these filters? Thanks.
ok..one difference you can find is
Ex URL: "https://stackoverflow.com/questions/ask?title=why%"
so doing a like :
select * from table where column like '%/questions/%'
doing FINDSTRING(url,"/questions/",1)=1
should give you exact results !
SSIS is case sensitive, whereas your SQL query is likely being evaluated in a case insensitive fashion.
Try FINDSTRING(LOWER(url), "questions", 1) >= 1
Or, if you prefer the SSIS answer, try where url like '%questions%' collate Latin1_General_CS_AS
I have a query like
SELECT *
FROM myTable
WHERE key LIKE 'XYZ'
The value 'XYZ' is entered by users (and may include % and _)
If I construct the query using string concatenation it runs in 10 seconds.
But this is unsafe, and I should use a parameterised query.
So I'm constructing the query using the odbc command object and it's execute method, and passing a parameter.
SELECT *
FROM myTable
WHERE key LIKE ?
Unfortunately the parameterised SQL execute method takes a full minute.
This query is one of many that are part of a drill-down / investigation package, and I've had similar slow downs with all the parameterised queries (compared to string concatenation).
How do I find out where the time is going (and fix it) ?
Here's my guess without further information.
I've had similar problems on SQL Server. In SQL Server when the column on your table is 'varchar' and the parameterised query parameter is 'nvarchar' (or vice versa), this causes SQL Server to ignore an available index because the parameter type doesn't match the index type, which in turn results in a table scan.
It's possible the same thing happens for Sybase. If you can see the generated query you can confirm if there's a type mismatch.
If this is the case, then two solutions would be
explicitly set the type of the parameter to match the column type
change the type of the column to match the parameter type being generated
Mitch had the right suggestion.
I had to change the connection string to use the OLEDB driver, then I could set the options:
Optimize Prepare=None
Select Method=Direct
I have an Access database set up on a domain hosting service. I am connecting to it through SQL. However, I need all of my queries to be case sensitive, and as far as I know the way the server is set up on the hosting service is it's NOT case sensitive. Is there a certain command that I could use in my SQL which would make the query case sensitive?
Do you need to set the entire DB to case sensitive, or is it just part of some queries. If it is a query term then you can use these to force case sensitive matching:
StrComp("A","a",0)
The 0 in the method signature is to perform a binary comparison giving you the case sensitivity you want. It returns an integer.
WHERE StrComp('myText1', 'MYTeXt1', 0) = 0
Documentation
I think you can add collate after the WHERE clause.
SELECT col FROM table
WHERE col COLLATE Latin1_General_CS_AS = 'value'
The classic way to query an SQL database case-insensitively from Java is as follows:
String name = ...; // get the user's input (case is unknown)
String sql = "select * from Person where lower(name) = ?";
Object jdbcBindVariable = name.toLowerCase();
// ... using JDBC, bind that variable and run the SQL query
The problem is that lower-casing is a locale-specific operation. For example, lower-casing the letter "I" gives different results in English and Turkish. In the above code, there are two lower-casing operations:
The String#toLowerCase() method
The lower() database function
How can I make sure that Java and the database are using the same locale and thereby performing a valid comparison?
I'm aware that the String class has a toLowerCase(Locale) method, but how do I know what Locale the database is using? Can I check this programatically, or do I have to hard-code the locale to the one with which I think the database (in this case Oracle 10g) is configured?
The simple answer is let the database do it.
That way the way the bind variable is put into lower case will be consistent with the way the column value is put into lowercase.
String sql = "select * from Person where lower(name) = lower(?)";
... but how do I know what Locale the database is using? Can I check this programmatically ...
There doesn't appear to be a portable (database independent) way to do this, but you can apparently use the following query to get the charset used by an Orable database:
select value from nls_database_parameters where parameter = 'NLS_CHARACTERSET';
This page gives more details.
As for actually doing the comparison, you would be best off (*) letting the database take care of the lower-casing, as #Gary suggests. The JDBC driver will take care of converting Java (UTF-16) Strings into whatever the database is using.
(* In fact, I don't think you have much choice, unless you are prepared to wear the cost of storing mixed-case and lower-case copies of all queriable strings in the database.)