This is very difficult to explain, so I took pictures. The first is the error I'm getting, the second is that section of code. Can anyone help me determine what is wrong? I can provide more information if needed.
http://tinypic.com/r/14dlu2v/5
http://tinypic.com/r/2057grb/5
EDIT: Fixed!
Maybe you may want to check whether you got a return set. See the documentation below, look at example two.
http://www.php.net/manual/en/mysqli.quickstart.statements.php
Related
I'm beginner in MySQL and I want to make a request to find all tables with this word "Ostéotomie", it works only if I write "%Ost%" and not "%Ostéotomie%"
The fact is that it shows me only 4 results instead of the 9 I need.
Here is a SQL Fiddle to show what I mean : SQL Fiddle
The table wasn't created by me, I'm working on a search bar from a project which isn't mine.
I don't know if you can help me, if I've putted enough information.
Thanks in advance.
I tried replacing é with % and the query gave me expected results.
https://dev.mysql.com/doc/refman/8.0/en/charset-binary-collations.html
Maybe this solved your Problem.
After I typed 13,10 into the value box as shown in the image1, it comes up with decimal(13,0). What's the problem?
Thanks.
You might be seeing the effect of this bug, which exists with version 4.6.4 and will be fixed with the upcoming version 4.6.5. You can also apply the patch yourself.
The preview may be incorrect, but try saving it and see if that is correct. In my testing this is working, but we may be on different versions. Also, if it saves incorrectly (if there is a bug in phpMyAdmin) you can always do an alter (Change button) and see if that block of code handles it correctly. If all else fails, there's always the command line to sort it out.
I have the following 2 mysql select queries within a PHP if statement:
if ($chooselocn =="") {
$query = "
SELECT $table.*, outcodepostcodes.lat, outcodepostcodes.lng
FROM $table
LEFT JOIN outcodepostcodes
ON UPPER($table.postcode)=outcodepostcodes.outcode
WHERE
$where_no_and
AND
(hide='0' OR hide IS NULL OR hide='')
ORDER BY rent $reihenach LIMIT $offset, $rowsPerPage
";
}
else {
$query = "
SELECT $table.*, outcodepostcodes.lat, outcodepostcodes.lng
FROM $table
LEFT JOIN outcodepostcodes
ON UPPER($table.postcode)=outcodepostcodes.outcode
WHERE
$where_no_and
AND
outcodepostcodes.lat <= $latpoint
AND
(hide='0' OR hide IS NULL OR hide='')
ORDER BY rent $reihenach LIMIT $offset, $rowsPerPage
";
}
The first query works but the second returns this error message:
Query failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'AND outcodepostcodes.lat <= 51.491239000000000 AND (hide='0' OR hide IS NULL OR' at line 8
Even if I remove the:
AND
outcodepostcodes.lat <= $latpoint
from the 2nd query making the two identical I still get similar error msg in the second.
Any ideas greatly appreciated.
You probably have an empty $where_no_and variable, thus your second query gets to contain ... WHERE AND ... which is not valid SQL
I bet the variable $where_no_and causes the issue.
It seems like it is empty causing the WHERE statement to be followed by the AND.
So this line:
WHERE $where_no_and AND outcodepostcodes.lat <= $latpoint AND (hide='0'...
is like this:
WHERE AND outcodepostcodes.lat <= $latpoint AND (hide='0'...
The WHERE AND is not valid syntax.
Even after you removed the part:
AND outcodepostcodes.lat <= $latpoint
Your line would look like this:
WHERE $where_no_and AND (hide='0'...
Which would result in this:
WHERE AND (hide='0'...
Again you have WHERE AND which is not valid syntax.
Try to make sure that the $where_no_and variable is not null or empty.
If your business logic says that this variable COULD be empty then you have to write a couple of more lines of code to handle this case.
Cheers!
This is not a solution but a way to find the bug.
Just put a var_dump($query) after the if(). It's impossible to tell without knowing what the variables actually contain. The dump will be before the query is executed, so you'll see very well what is going on there.
If the query is still apparently correct post the dump here and we'll see.
Why do if/then if the queries are supposed to be identical regardless of the condition?
That said, your variables that form the query are probably different depending on the value of $chooselocn. I would start by dumping the actual query into debugging log or the browser as well as the variables that compose it and it would shed some light.
I should also add the standard warning about watching out for SQL injections.
Thank you, thank you, thank you and a MASSIVE THANK YOU to every one who replied to my question!!!!
#Gordon Linoff, thank you for being the first to respond in the right direction
#David Lavieri, thank you for the useful suggestion
#Tudor Constantin, thank you for being the first to explain the crux of the problem
#pid, thank you for the useful suggestion
#user2399432, a massive thank you for the very lengthy, detailed and exhaustive explanation of EXACTLY what was going on.
While everyone pointed me in the right direction, and unfortunately I was busy elsewhere to follow up on those early suggestions, I must upvote #user2399432 for going to all that trouble to make absolutely sure that it all sunk in and there were no two ways about it.
Just as background info, this is an extremely old site I have come back to work on, after a three year absence from coding, and I noticed that I had the following lines of code in this particular script:
///THIS IS THE CRUCIAL LINE BELOW:
$where_no_and = rtrim($where, 'AND ');
///End of crucial line and then TEST
//var_dump($where_no_and);//VERY USEFUL DIAGNOSTIC! INDISPENSIBLE! MUST RETAIN! DO NOT DELETE!
//echo "#6 City is:".$lc_city;//USEFUL DIAGNOSTIC
So I must have had the same problem those many years ago and dealt with it accordingly using var_dump($where_no_and);
Be that as it may, I was well and truly stuck this time round and your valuable help has knocked down the barricades, SO THANK YOU TO ALL!
I just want to say sorry if this is a really easy question but I'm overworked with this site to the point where parts of the code that are working aren't making sense, any help in telling me why this MYSQL UPDATE isn't working would be greatly appreciated
mysql_query("UPDATE setlist SET song_artist='$song_artist1' AND song_name='$song_name1' WHERE song_id='$song_id'");
When it does work the value is being entered as a 0 (which I believe would mean NULL but all of the variables are working correctly as I have used a die statement with the variables inputted into it, I am also not generating any errors from mysql_error, any help would be appreciated, thanks!
This is my MYSQL table setout.
song_id
song_artist
song_name
Replace AND with a comma,should work.
'$song_id'
remove the quotes.
I have an SQL query that works on older version of MySQL4 but won't work on my current version of 5.5
I'm hoping someone can see what I can't see with this.
select tblprefix_groups_permissions.permission_name
from tblprefix_groups_permissions, tblprefix_users, tblprefix_permissions
where tblprefix_groups_permissions.permission_name = tblprefix_permissions.permission_name
and tblprefix_groups_permissions.group_id = tblprefix_users.group_id
and (tblprefix_users.user_id = '==NUMERIC ID=='
and (tblprefix_permissions.permission_name = 'ADMIN::SETTINGS::VIEW'
or tblprefix_permissions.permission_name = 'ALL'))
The SQL statement should be pretty self explanitory as to what it does, I don't see where the hangup could be. It is suppost to return a list if it returns nothing then the user is rejected.
It looks like you have wrongly placed the quotes here:
ADMIN::SETTINGS::VIEW''
Anyway... are you sure that works in MySQL 4?
BTW, you can remove the outer brackets.
The statement is correct, I overlooked the fact that the statement also checks to make sure the Permission is in the Master Permissions table ie: tblprefix_permissions.permission_name I had not put the permission into the Master Permissions table yet
So that makes me stupid or just tired LOL sorry guys, good work though and thanks for the quick responses