I'm using PDO to connect to MySQL. Everything is working fine, except this doesn't work.
Does anyone knows why? And how should i do it?
SELECT * FROM flagIt WHERE :flagids LIKE CONCAT('%', flagIt.flagIt_id, '%')
:flagids is equivalent to a string like "ID1 ID2 ID3".
EDIT (just to compare)
SELECT * FROM flagIt WHERE 'ID1 ID2 ID3' LIKE CONCAT('%', flagIt.flagIt_id, '%)
If i use like this, it works fine, so...why it does not work with :flagids?
I hope you understand my problem.
Thank you very much.
EDIT
I tried:
"SELECT * FROM flagIt WHERE flagIt.flagIt_id IN(:flagids)"
and as Hobo Sapiens suggested
"SELECT * FROM flagIt WHERE FIND_IN_SET(flagIt.flagIt_id, :flagids)"
and nothing works!!!!!!!!!
This is the query you're submitting to PDO::prepare():
SELECT * FROM flagIt WHERE :flagids LIKE CONCAT('%', flagIt.flagIt_id, '%')
The process of preparing a statement doesn't just involve evaluating the contents of the placeholders, substituting them in a string and executing the resulting query.
A prepare asks the server to evaluate the query and prepare an execution plan that includes the table and indexes it will use. For that it needs to know which columns of which tables it must work with, which is why one cannot use a placeholder where you would need an identifier.
The problem with your query is that the server has no way to know at the time it prepares the statement whether the placeholder represents a string literal or a column identifier. Without that information, the preparation cannot be done, and your prepare will fail.
If you have some flexibility over the value you're using in :flagids you could use find_in_set():
SELECT * FROM flagIt WHERE find_in_set(flagIt_id, :flagids)
where a variable containing, for example, 'ID1,ID2,ID3' is bound to :flagids.
This will be fine for small lists, but will be slow for a large list.
MySQL reference for find_in_set()
Related
Sorry about the title, I wasn't sure how to word it
I'm wanting to make a instant messaging system with PHP (I've done ajax for it) but I'm not sure how to get the query, I'm wanting something like this:
"SELECT * FROM messages WHERE user='$to' AND sender='$username' OR user='$username' AND sender='$to'"
Does anyone know if this is possible? Or a mysqli_fetch_array for two invididual queries on the same variable.
You can use parenthesis to use multiple operations to work as single operation in query. This is the typical approach anyway, and very useful for using multiple AND, OR operators in a query.
For you case, query should be like
"SELECT * FROM messages WHERE ( user='$to' AND sender='$username' ) OR ( user='$username' AND sender='$to' )"
Notice that tho we used 4 conditions, but with parenthesis we shrieked it into 2 separate conditions and ultimately one OR operation in the query.
Some good reading about this stuff at this article in case you want to dig it more
I have a string returned from a function "'aa','bb','cc',..."(the function uses GROUP_CONCAT). I want to use this as a condition in the IN clase of mysql.
SELECT name,class,comment
FROM vwstudent v
WHERE name IN (select func())
I want the query to act like
SELECT name,class,comment
FROM vwstudent v
WHERE name IN ('aa','bb','cc','dd',..)
I assume ('aa','bb','cc','dd',..) is acting as a whole string here and isn't generating any result. What can I do to run this query error less.
I'm not sure if it'll help. But you might be able to hack something together by using PREPARE and EXECUTE as described here: How To have Dynamic SQL in MySQL Stored Procedure
... but that's completely new to me. I've never used anything like that in MySQL.
hope that you are doing fine
I am having very hard time writing a query
Here is my question explained
i have a database table say "jreviews_content" which has a field named "jr_produits"
In "jr_produits" the data is is the format *ryan-decosta*tom-gosling* so i want a search query that is exact word based i.e if the user type "rya" the mysql should not return anything
but if the user type ryan then it should return the row likewise if the user type "gos" the mysql should not return anything
but if the user type gosling then it should return the row where ryan and gosling are the exact words
the query that i am writing are
SELECT *
FROM `jreviews_content`
WHERE jr_produits LIKE '%*ryan-%' or jr_produits LIKE '%-ryan*%'
or jr_produits LIKE '%*ryan*%' or jr_produits LIKE '%-ryan-%';
I want that to be done in some other way that is more efficient(either by regular expression or any other method)
SELECT * FROM `jreviews_content` WHERE jr_produits REGEXP '^[*-]ryan[*-]$'
It doen't fetch anything
neither does
SELECT * FROM `jreviews_content` WHERE jr_produits like '%[*-]ryan[*-]%'
Please suggest something
Try the MySQL regex word boundary markers. They're documented about halfway down this page:
SELECT *
FROM jreviews_content
WHERE jr_produits REGEXP '[[:<:]]ryan[[:>:]]'
Note that I don't have MySQL access today, so this is untested.
Also heed what #user1032531 said. Records with values like *ryan-decosta*tom-gosling* almost always mean "bad design".
I'm writing a simple diagnostic query then attempting to execute it in the Oracle 10g SQL Scratchpad. EDIT: It will not be used in code. I'm nesting a simple "Select *" and it's giving me errors.
In the SQL Scratchpad for Oracle 10g Enterprise Manager Console, this statement runs fine.
SELECT * FROM v$session sess, v$sql sql WHERE sql.sql_id(+) = sess.sql_id and sql.sql_text <> ' '
If I try to wrap that up in Select * from () tb2 I get an error, "ORA-00918: Column Ambiguously Defined". I didn't think that could ever happen with this kind of statement so I am a bit confused.
select * from
(SELECT * FROM v$session sess, v$sql sql WHERE sql.sql_id(+) = sess.sql_id and sql.sql_text <> ' ')
tb2
You should always be able to select * from the result set of another select * statement using this structure as far as I'm aware... right?
Is Oracle/10g/the scratchpad trying to force me to accept a certain syntactic structure to prevent excessive nesting? Is this a bug in scratchpad or something about how oracle works?
When Oracle parses a SELECT *, it expands it out to an actual list of the columns to be selected. Since your inline view contains two columns named SQL_ID, this results in an ambiguous reference.
Interestingly, using ANSI join syntax seems to cause it to alias the duplicate column names automatically, and therefore avoids the error.
select * from
(select * from v$session sess left outer join v$sql sql on sql.sql_id=sess.sql_id and sql.sql_text <> ' ')
Incidentally, it's not clear to me why you chose that condition on sql_text. I don't expect that column would ever contain a single space. Are you really trying to filter out NULLs? If so, why use an outer join at all?
One of the general rules of thumbs at my place of employment is that SELECT * is never allowed. Explicitly define what columns you need; not only is it more readable, but less likely to have issues down the road
The following doesn't work, but something like this is what I'm looking for.
select *
from Products
where Description like (#SearchedDescription + %)
SSRS uses the # operator in-front of a parameter to simulate an 'in', and I'm not finding a way to match up a string to a list of strings.
There are a few options on how to use a LIKE operator with a parameter.
OPTION 1
If you add the % to the parameter value, then you can customize how the LIKE filter will be processed. For instance, your query could be:
SELECT name
FROM master.dbo.sysobjects
WHERE name LIKE #ReportParameter1
For the data set to use the LIKE statement properly, then you could use a parameter value like sysa%. When I tested a sample report in SSRS 2008 using this code, I returned the following four tables:
sysallocunits
sysaudacts
sysasymkeys
sysaltfiles
OPTION 2
Another way to do this that doesn't require the user to add any '%' symbol is to generate a variable that has the code and exceute the variable.
DECLARE #DynamicSQL NVARCHAR(MAX)
SET #DynamicSQL =
'SELECT name, id, xtype
FROM dbo.sysobjects
WHERE name LIKE ''' + #ReportParameter1 + '%''
'
EXEC (#DynamicSQL)
This will give you finer controller over how the LIKE statement will be used. If you don't want users to inject any additional operators, then you can always add code to strip out non alpha-numeric characters before merging it into the final query.
OPTION 3
You can create a stored procedure that controls this functionality. I generally prefer to use stored procedures as data sources for SSRS and never allow dynamically generated SQL, but that's just a preference of mine. This helps with discoverability when performing dependency analysis checks and also allows you to ensure optimal query performance.
OPTION 4
Create a .NET code assembly that helps dynamically generate the SQL code. I think this is overkill and a poor choice at best, but it could work conceivably.
Have you tried to do:
select * from Products where Description like (#SearchedDescription + '%')
(Putting single quotes around the % sign?)
Dano, which version of SSRS are you using? If it's RS2000, the multi-parameter list is
not officially supported, but there is a workaround....
put like this:
select *
from tsStudent
where studentName like #SName+'%'
I know this is super old, but this came up in my search to solve the same problem, and I wound up using a solution not described here. I'm adding a new potential solution to help whomever else might follow.
As written, this solution only works in SQL Server 2016 and later, but can be adapted for older versions by writing a custom string_split UDF, and by using a subquery instead of a CTE.
First, map your #SearchedDescription into your Dataset as a single string using JOIN:
=JOIN(#SearchedDedscription, ",")
Then use STRING_SPLIT to map your "A,B,C,D" kind of string into a tabular structure.
;with
SearchTerms as (
select distinct
Value
from
string_split(#SearchedDescription, ',')
)
select distinct
*
from
Products
inner join SearchTerms on
Products.Description like SearchTerms.Value + '%'
If someone adds the same search term multiple times, this would duplicate rows in the result set. Similarly, a single product could match multiple search terms. I've added distinct to both the SearchTerms CTE and the main query to try to suppress this inappropriate row duplication.
If your query is more complex (including results from other joins) then this could become an increasingly big problem. Just be aware of it, it's the main drawback of this method.