November 11, 2011 at 9:56 am
I have a table with a field with values given below. the ID field is a varchar type
ID
---
2|4|6
These 2,4 and 6 are actually a primary key values of a Master table.
i want the sql query to find whether the field contains the value 2.
One thing is of sure that we cannot use LIKE or IN operator as it will not provide correct solutions.
How to check only the numeric values at the same time ignoring the | symbol using SQL queries??
Please help me.
November 11, 2011 at 10:01 am
ID
---
2|4|6
It's bad design. If you have control on database schema, re-design it.
November 11, 2011 at 10:03 am
Agreed with Dev, but you can do it with a LIKE:
SELECT
*
FROM
(
SELECT '2|4|6'
) SampleTable(ID)
WHERE
'|' + ID + '|' LIKE '%|2|%'
November 11, 2011 at 10:05 am
mvijaykumar.mca (11/11/2011)
I have a table with a field with values given below. the ID field is a varchar typeID
---
2|4|6
These 2,4 and 6 are actually a primary key values of a Master table.
i want the sql query to find whether the field contains the value 2.
One thing is of sure that we cannot use LIKE or IN operator as it will not provide correct solutions.
How to check only the numeric values at the same time ignoring the | symbol using SQL queries??
Please help me.
Hello and welcome to SSC!
It appears that you have forgotten to post a few details, so I'm unsure what your actual question is!
What we could do with from you are four things: A clear description of your problem, DDL scripts, sample data in a readily consumable format and expected results.
When you have time, please read this article[/url] about the best way to provide us with working sample data and DDL scripts. This will allow the unpaid volunteers of this site to provide you with working, tested code for your particular problem.
For now, here's a best guess at your solution.
BEGIN TRAN
DECLARE @TABLE AS TABLE (ID VARCHAR(5))
INSERT INTO @TABLE
SELECT '2|3|5'
UNION ALL SELECT '1|2'
UNION ALL SELECT '1|3|5'
--This
SELECT ID
FROM @TABLE
WHERE ID LIKE '%2%'
--Or this
SELECT ID
FROM @TABLE
WHERE CHARINDEX('2',ID) > 0
ROLLBACK
You could also try a splitter, like the one in this article[/url]. That would allow you to check the split values for the value you are searching for.
November 11, 2011 at 10:10 am
Peter Brinkhaus (11/11/2011)
Agreed with Dev, but you can do it with a LIKE:
SELECT
*
FROM
(
SELECT '2|4|6' -- '3|24|4'
) SampleTable(ID)
WHERE
'|' + ID + '|' LIKE '%|2|%'
Can we try the same code with ID ''3|24|4''
November 11, 2011 at 10:10 am
a lot of the work around examples so far would return false positives if the values are two or more digits, thought right? 2|5|21|23|55 for example
redesign, or split the data on the | character
Lowell
November 11, 2011 at 10:14 am
Dev (11/11/2011)
Peter Brinkhaus (11/11/2011)
Agreed with Dev, but you can do it with a LIKE:
SELECT
*
FROM
(
SELECT '2|4|6' -- '3|24|4'
) SampleTable(ID)
WHERE
'|' + ID + '|' LIKE '%|2|%'
Can we try the same code with ID ''3|24|4''
I'm not sure what you mean. In case of ID='3|24|4' nothing is returned, which is the requirement, I guess.
November 11, 2011 at 10:17 am
Lowell (11/11/2011)
a lot of the work around examples so far would return false positives if the values are two or more digits, thought right? 2|5|21|23|55 for exampleredesign, or split the data on the | character
No need for a string splitter. Also Cadavre's solution can be simply modified to leave out the false positives:
SELECT
ID
FROM
(
SELECT '2|3|5'
UNION ALL SELECT '1|22'
UNION ALL SELECT '1|3|5'
) SampleTable(ID)
WHERE
CHARINDEX('|2|', '|' + ID + '|') > 0
November 11, 2011 at 10:36 am
Thanks Peter..
SELECT *
from Metatags WHERE
'|' + MetatagDesc + '|' LIKE '%|2|%'
If the field contains 2|23|4 , and am searching 23, its shud search only 23 not 2, dats the scenario i was looking for and It worked....
Thanks for everyone for the quick response... 🙂
November 11, 2011 at 10:42 am
mvijaykumar.mca (11/11/2011)
Thanks Peter..SELECT *
from Metatags WHERE
'|' + MetatagDesc + '|' LIKE '%|2|%'
If the field contains 2|23|4 , and am searching 23, its shud search only 23 not 2, dats the scenario i was looking for and It worked....
Thanks for everyone for the quick response... 🙂
I insist you not to go with this solution. If it would have any column but key, there is no issue. You are playing with IDs. In future, there would be many issues just because of one wrong decision (or quick fix).
November 11, 2011 at 10:49 am
Peter Brinkhaus (11/11/2011)
No need for a string splitter. Also Cadavre's solution can be simply modified to leave out the false positives:
Your solution is not SARGable. If you care at all about performance, there most certainly is a need to at least consider a string splitter.
Drew
J. Drew Allen
Business Intelligence Analyst
Philadelphia, PA
November 11, 2011 at 10:59 am
drew.allen (11/11/2011)
Peter Brinkhaus (11/11/2011)
No need for a string splitter. Also Cadavre's solution can be simply modified to leave out the false positives:Your solution is not SARGable. If you care at all about performance, there most certainly is a need to at least consider a string splitter.
Drew
I realized that and I was actually responding to the statement that a LIKE wouldn't work. But I'm wondering if a string splitter would do any good in terms of performance in this case. Sure, you can split the string into a result set with a row for each ID, but there's no index on it. So how will that be SARGable.
November 11, 2011 at 12:49 pm
Peter Brinkhaus (11/11/2011)
drew.allen (11/11/2011)
Peter Brinkhaus (11/11/2011)
No need for a string splitter. Also Cadavre's solution can be simply modified to leave out the false positives:Your solution is not SARGable. If you care at all about performance, there most certainly is a need to at least consider a string splitter.
Drew
I realized that and I was actually responding to the statement that a LIKE wouldn't work. But I'm wondering if a string splitter would do any good in terms of performance in this case. Sure, you can split the string into a result set with a row for each ID, but there's no index on it. So how will that be SARGable.
It depends on the source of the string you're splitting. If you're splitting a parameter, then there is only one string to split, which will be very fast, and then you can potentially use an index seek on the table with the parsed values. If the source of the string is a field on a table, then the function will need to be called for each field which will affect the performance.
Drew
J. Drew Allen
Business Intelligence Analyst
Philadelphia, PA
November 11, 2011 at 12:54 pm
drew.allen (11/11/2011)
Peter Brinkhaus (11/11/2011)
drew.allen (11/11/2011)
Peter Brinkhaus (11/11/2011)
No need for a string splitter. Also Cadavre's solution can be simply modified to leave out the false positives:Your solution is not SARGable. If you care at all about performance, there most certainly is a need to at least consider a string splitter.
Drew
I realized that and I was actually responding to the statement that a LIKE wouldn't work. But I'm wondering if a string splitter would do any good in terms of performance in this case. Sure, you can split the string into a result set with a row for each ID, but there's no index on it. So how will that be SARGable.
It depends on the source of the string you're splitting. If you're splitting a parameter, then there is only one string to split, which will be very fast, and then you can potentially use an index seek on the table with the parsed values. If the source of the string is a field on a table, then the function will need to be called for each field which will affect the performance.
Drew
Based on the OP's response it looks like the latter
SELECT *
from Metatags WHERE
'|' + MetatagDesc + '|' LIKE '%|2|%'
November 11, 2011 at 1:21 pm
Even so, the performance may still be better using the string splitter than without. The only way to now for sure is thorough testing, which is why I initially said that a string splitter was at least worth considering.
Drew
J. Drew Allen
Business Intelligence Analyst
Philadelphia, PA
Viewing 15 posts - 1 through 15 (of 31 total)
You must be logged in to reply to this topic. Login to reply