I'm trying to find out what the problem is since hours. I have a varchar(255).
works:
mysql_query("UPDATE `servers` SET `url`='quicktest' WHERE `id`=63");
doesn't work:
mysql_query("UPDATE `servers` SET `url`='quick-test' WHERE `id`=63");
What is wrong with the "-" chars that it doesn't work? I mean I can update it in phpmyadmin without problems and sometimes it even works via mysql_query. (1 of 20 cases)
About mysql_query I know that it is outdated but it is just updating internal stuff.
Update #1
I did not had this problem on an old debian 6 server but since it is on ubuntu 13.10 with maria db and php5-fpm I can´t use this script any more and I don´t get any errors.
Update #2
As it looks like it was related to either caching via the apache modules or the google pagespeed module.
Not a solution, but maybe it's worth to try:
$temp_url = mysql_real_escape_string('quick-test');
mysql_query("UPDATE `servers` SET `url`='".$temp_url."' WHERE `id`=63");
Related
I have a Magento 1.9.2.1 . And it successfully running on Apache2 and MySQL 5.5.
I have tried to migrate it to another server and used NGINX and MySQL 5.7 for it.
But website started to be very slow (12 seconds against 2).
After several hours of debug I have found that there is a problem in one query:
SELECT
`main_table`.`entity_id`,
`main_table`.`name`,
`main_table`.`path`,
`main_table`.`is_active`,
`main_table`.`is_anchor`,
`url_rewrite`.`request_path`
FROM
`catalog_category_flat_store_1` AS `main_table`
LEFT JOIN
`core_url_rewrite` AS `url_rewrite` ON
`url_rewrite`.`category_id` = `main_table`.`entity_id` AND
`url_rewrite`.`is_system` = 1 AND
`url_rewrite`.`store_id` = 1 AND
`url_rewrite`.`id_path` LIKE 'category/%'
WHERE
(`main_table`.`include_in_menu` = '1') AND
(`main_table`.`is_active` = '1') AND
(`main_table`.`path` like '1/2/%')
ORDER BY
`main_table`.`position` ASC;
And on explain I have found that there is no index used. On the old MySQL 5.5 server explain command showing index in use. Once I force usage of index - new server answers in 0.01s instead of 10s. But I think that it is not good idea to change sourcefiles of magento code.
Is there a way to force MySQL 5.7 work in similar way as 5.5 in index choosing?.
Sadly only MySQL downgrade from 5.7 to 5.5 fixed similar issue for me.
Magento sql query have no index
Just for anyone else searching this like I was today, there's a simple fix you can apply to app/code/core/Mage/Catalog/Helper/Category/Url/rewrite.php
details here - https://github.com/hvanmegen/magento-mysql-5.7-join-fix
BACKGROUND: I am using PHPMyAdmin tool to run MySQL queries. MySQL version is 5.1.55. I have been using MySQL and this PHPMyAdmin tool for about 7 years and have never seen this error. I am trying to do a simple update query changing ne to gb (column = team, table = info). When I use PHPMyAdmin to try to make the changes,
I get the error message:
UPDATE `pickem`.`info` SET `team` = 'gb' WHERE CONVERT(`info`.`team` USING utf8) = \'ne\'.
QUESTION: What is going wrong here? What is the CONVERT Using UTF8 message coming from. How can I get this to just update the fields I want? I have tried to type the SQL code in myself ex: update info set team ="gb" where team = "ne" , but that does not work either. I get the error message:
There seems to be an error in your SQL query. The MySQL server error output below, if there is any, may also help you in diagnosing the problem
ERROR: Unknown Punctuation String # 22
STR: =\
SQL: update info set team =\"gb\" where team = \"ne\"
It seems the system is putting the slashes in there and it is not letting me do this simple update query.
I appreciate any advice on how to fix this.
Thanks!
You are using phpMyAdmin, right? Try using HeidiSQL.
Also check your PHP version, gpc_magic_quotes is already removed at PHP 5.4.0
I tried running your code on phpMyAdmin, removed the backslashes at \'ne\' and its running fine.
Try running a simple update query in HeidiSQL and check if the problem exists.
UPDATE `pickem`.`info` SET `team` = 'gb'
If it runs fine, modify it like
UPDATE `pickem`.`info` SET `team` = 'gb' WHERE `team` = 'ne'
Additional sidenote - check the encoding and data types. You might have overlooked something...
If your query runs fine on HeidiSQL, you can safely assume that something is wrong with your phpMyAdmin installation/configuration
EDIT:
Are the values you are providing contain '\' inside them? If so, you have to do it like
UPDATE `pickem`.`info` SET `team` = 'gb\\'
EDIT 2:
For the meantime, try to use this to solve your problem temporarily.
UPDATE `pickem`.`info` SET `team` = CONCAT('en') WHERE `team` = CONCAT('gb')
EDIT 3:
If all else fails, you probably should get this or this. Since you are on PHP 5.3, I am afraid to say that the gpc_magic_quotes option might have been enabled by your hosting provider. Contact them.
Hey, I've been investigating SQL_BIG_SELECTS, but the MySQL documentation so far has been pretty unhelpful. I'm looking for some insight as to preventing errors like the one below from appearing.
ERROR 1104: The SELECT would examine too many records and probably take a very long time.
Check your WHERE and use SET OPTION SQL_BIG_SELECTS=1 if the SELECT is ok
At how many rows does MySQL decide that a query is a "BIG SELECT"?
Will proper indexing usually solve this issue?
Is SQL_BIG_SELECTS considered a "last resort", or is it good practice?
How would someone set "SQL_BIG_SELECTS=1" in configuration (without having to execute the query)?
Are there any other alternatives worth knowing?
Thanks in advance!
MySQL determines whether or not a query is a 'big select' based on the value of 'max_join_size'. If the query is likely to have to examine more than this number of rows, it will consider it a 'big select'. Use 'show variables' to view the value of the max join size.
I believe that indexing and particular a good where clause will prevent this problem from occuring.
SQL_BIG_SELECTS is used to prevent users from accidentally executing excessively large queries. It is okay to set it to ON in mysql.cnf or using the command-line option at startup.
You can set SQL_BIG_SELECTS in my.cnf or at server startup. It can also be set on a session basis with SET SESSION SQL_BIG_SELECTS=1.
Not that I can think of. I would just check your query to make sure that you really need to use it. Our servers have it turned on by default, and max_join_size is very large.
You cannot set SQL_BIG_SELECTS in my.cnf or at server startup as it is a session only parameter. I am using MySQL 5.0.60.
As someone has post before, you can not set SQL_BIG_SELECTS on my.cnf at server startup. This kind of variable does not support that.
I had a same problem with a Symfony application showing this annoying error:
The SELECT would examine more than MAX_JOIN_SIZE rows; check your WHERE and use SET SQL_BIG_SELECTS=1 or SET SQL_MAX_JOIN_SIZE=# if the SELECT is okay
But you can increase the number of varialbe
max_join_size which is related to sql_big_selects
I was able to fix it executing a command as privileged mysql user:
# SET GLOBAL max_join_size=18446744073709551615;
Or you can include it in my.cnf because max_join_size is allowed to set up in configuration file
Well, I hope this can help someone else.
I had more than 2000k records in db, and my query was big-select with exhaustive comparison for duplication removal and updation of certain field...I was told the same by mysql (current version on answer date), and I ended up using index on 2 fields involved in where clause...this should help others too...steps which worked for me were:
Set Index on field
ANALYZE TABLE
run the query
HTH
Following command works for me
SET GLOBAL max_join_size=18446744073709551615;
But what do i need to put in my.cnf file instead of the command?
Btw, i'm using "5.6.12 MySQL Community Server"
SET SESSION SQL_BIG_SELECTS =1;# MySQL returned an empty result set (i.e. zero rows).
SELECT a.`HACtrl` , b.`HBCtrl` , c.`HDCtrl`
FROM `HO110BLote` AS a
LEFT JOIN `HO113BPago` AS b ON ( b.HBHACtrl = a.HACtrl )
LEFT JOIN `HO113BRecibos` AS c ON ( c.HDHBCtrl = b.HBCtrl )
WHERE HAManzana = '03'
AND HALote = '09'
LIMIT 0 , 100
I do have a weird problem inside my custom wordpress script. I want to update my database and I used this line of code to do it:
$update1 = $wpdb->query($wpdb->prepare("UPDATE wp_avg_rate SET avg='$raty' WHERE user_id= '$user->ID'"));
Problem was now, that my page loaded about 20 seconds so I started debbuging and I found out that $wpdb->prepare needs a second parameter. I tried this code and right now it is working:
$update1 = $wpdb->query($wpdb->prepare("UPDATE wp_avg_rate SET avg='$raty' WHERE user_id= %d'", $user->ID));
Problem is now, that in my opinion there is a ' (at the end by %d) closed but never opened so I tried these codes:
$update1 = $wpdb->query($wpdb->prepare("UPDATE wp_avg_rate SET avg='$raty' WHERE user_id= '%d'", $user->ID));
$update1 = $wpdb->query($wpdb->prepare("UPDATE wp_avg_rate SET avg='$raty' WHERE user_id= %d", $user->ID));
As soon as I am using those codes the site load is again more than 20 seconds. Can someone help me and tell me what the correct syntax for the database update is?
The correct syntax for this SQL query is:
$update1 = $wpdb->query($wpdb->prepare("UPDATE wp_avg_rate SET avg='$raty' WHERE user_id= %d", $user->ID));
prepare will replace the %d with a sanitised integer of $user->ID
The 20 second delay you are seeing must be a problem with your database, database server, or your connection to it, which we can't troubleshoot given the information provided.
Here are things you can try
First and foremost make sure that the SQL is getting generated properly. Check out Debug Bar, and the SAVE_QUERIES option for wp-config
https://codex.wordpress.org/Debugging_in_WordPress
Next Check that you can perform these queries quickly using a MySQL Client. I would recommend using the mysql command line tool if possible but PHPMyAdmin or MySQL Workbench will do the job too
Finally if the query is correct and fast when executed in a client, then you might want to check your DNS settings. I have encountered similar problems caused by the Database Server not being able to resolve the WordPress server's hostname
Please let me know how that goes!
I got a very weird problem with oracle today.
I setup a new server with xampp for developing, i activated mssql and oracle and everything was just fine until i tried to execute an update statement.
Every select, insert, etc is working fine with PHP 5.3.
I also can parse the statement and get a ressource id back, but when i try to execute the statement my whole site is not responding.
no error, nothing. just timeout until i restart the apache.
here the code... it's the test code, so there should be no problem at all.
$conn = oci_connect('***', '***', '***');
$query ="UPDATE CHAR*** SET TPOS = 14, ID = 5, DIFF = 'J' WHERE ***NR = '3092308' AND LA*** = '5'";
echo $query;
echo '<br>';
echo $stid = oci_parse($conn, $query);
oci_execute($stid, OCI_DEFAULT);
oci_free_statement($stid2);
Any hints or ideas? :-(
I already tried to reinstall the oracle instant client and another version. I am using 10g like our db at the moment.
best regards
pad
The row may be locked by another session. If this is the case, your session will hang until the other transaction ends (commit/rollback).
You should do a SELECT FOR UPDATE NOWAIT before attempting to update a row (pessimistic locking):
If the row is locked, you will get an error and can return a message to the user that this record is currently being updated by another session. In most cases an explicit message is preferable to indefinite waiting.
If the row is available, you will make sure no session modifies its content until you commit (and thus you will prevent any form of lost update).
There are other reasons why a simple update may take a long time but they are less likely, for instance:
When you update an unindexed foreign key, Oracle needs to acquire a lock on the whole parent table for a short time. This may take a long time on a busy and/or large table.
There could be triggers on the table that perform additional work.
For further reading: pessimistic vs optimistic locking.