How to test an SQL Update statement before running it? - mysql

In some cases, running an UPDATE statement in production can save the day. However a borked update can be worse than the initial problem.
Short of using a test database, what are options to tell what an update statement will do before running it?

What about Transactions? They have the ROLLBACK-Feature.
#see https://dev.mysql.com/doc/refman/5.0/en/commit.html
For example:
START TRANSACTION;
SELECT * FROM nicetable WHERE somthing=1;
UPDATE nicetable SET nicefield='VALUE' WHERE somthing=1;
SELECT * FROM nicetable WHERE somthing=1; #check
COMMIT;
# or if you want to reset changes
ROLLBACK;
SELECT * FROM nicetable WHERE somthing=1; #should be the old value
Answer on question from #rickozoe below:
In general these lines will not be executed as once. In PHP f.e. you would write something like that (perhaps a little bit cleaner, but wanted to answer quick ;-) ):
$MysqlConnection->query('START TRANSACTION;');
$erg = $MysqlConnection->query('UPDATE MyGuests SET lastname='Doe' WHERE id=2;');
if($erg)
$MysqlConnection->query('COMMIT;');
else
$MysqlConnection->query('ROLLBACK;');
Another way would be to use MySQL Variables (see https://dev.mysql.com/doc/refman/5.7/en/user-variables.html
and
https://stackoverflow.com/a/18499823/1416909
):
# do some stuff that should be conditionally rollbacked later on
SET #v1 := UPDATE MyGuests SET lastname='Doe' WHERE id=2;
IF(v1 < 1) THEN
ROLLBACK;
ELSE
COMMIT;
END IF;
But I would suggest to use the language wrappers available in your favorite programming language.

In addition to using a transaction as Imad has said (which should be mandatory anyway) you can also do a sanity check which rows are affected by running a select using the same WHERE clause as the UPDATE.
So if you UPDATE is
UPDATE foo
SET bar = 42
WHERE col1 = 1
AND col2 = 'foobar';
The following will show you which rows will be updated:
SELECT *
FROM foo
WHERE col1 = 1
AND col2 = 'foobar';

Set Autocommit to OFF.
In MySQL, set autocommit=0; sets the autocommit off for the current session.
You execute your statement, see what it has changed, and then rollback if it's wrong or commit if it's what you expected!
The benefit of using transactions instead of running select query is that you can check the resulting set easily.

For testing update, hash # is your friend.
If you have an update statement like:
UPDATE
wp_history
SET history_by="admin"
WHERE
history_ip LIKE '123%'
You hash UPDATE and SET out for testing, then hash them back in:
SELECT * FROM
#UPDATE
wp_history
#SET history_by="admin"
WHERE
history_ip LIKE '123%'
It works for simple statements.
An additional practically mandatory solution is, to get a copy (backup duplicate), whenever using update on a production table. Phpmyadmin > operations > copy: table_yearmonthday. It just takes a few seconds for tables <=100M.

I've seen many borked prod data situations that could have been avoided by typing the WHERE clause first! Sometimes a WHERE 1 = 0 can help with putting a working statement together safely too. And looking at an estimated execution plan, which will estimate rows affected, can be useful. Beyond that, in a transaction that you roll back as others have said.
You can also use WHERE FALSE for MySQL, but keep in mind other DBMSes like SQL Server won't accept that.

One more option is to ask MySQL for the query plan. This tells you two things:
Whether there are any syntax errors in the query, if so the query plan command itself will fail
How MySQL is planning to execute the query, e.g. what indexes it will use
In MySQL and most SQL databases the query plan command is describe, so you would do:
describe update ...;

make a SELECT of it,
like if you got
UPDATE users SET id=0 WHERE name='jan'
convert it to
SELECT * FROM users WHERE name='jan'

In these cases that you want to test, it's a good idea to focus on only current column values and soon-to-be-updated column values.
Please take a look at the following code that I've written to update WHMCS prices:
# UPDATE tblinvoiceitems AS ii
SELECT ### JUST
ii.amount AS old_value, ### FOR
h.amount AS new_value ### TESTING
FROM tblinvoiceitems AS ii ### PURPOSES.
JOIN tblhosting AS h ON ii.relid = h.id
JOIN tblinvoices AS i ON ii.invoiceid = i.id
WHERE ii.amount <> h.amount ### Show only updatable rows
# SET ii.amount = h.amount
This way we clearly compare already existing values versus new values.

Just run an EXPLAIN query. So just write the word EXPLAIN before your query and it will give you info about how it would execute your update - finding rows, etc. But it won't execute it. However it will let you know if there are any syntax errors. So just use an explain!
EXPLAIN UPDATE ... SET ...

Run select query on same table with all where conditions you are applying in update query.

Related

Basic Update Statement gets a "1111; Invalid use of Group Function" error on Kace SMA using MariaDB

I'm guessing this is something really simple as there's only really 3 lines of code here causing me a problem!
I'm creating a custom rule on the Kace SMA that selects tickets and updates the title field.
For those unfamiliar, the select statement in the SMA pulls your select into the <TICKET_IDS> variable for you to feed to the update statement. In the test area I'm running it in I'm getting ~12 ID's which matches what I would expect.
Select works fine, and then when the update runs via EXECUTE I get "[1111: Invalid use of group function] in..."
Both statements below. My initial thought was it's to do with WHERE/HAVING but I'm simply feeding the update a list and not doing anything other than that. I am familiar with standard SQL but hadn't really messed about with MariaDB/MySQL much until now so I apologise if it's a completely basic thing I've done.
SELECT HD_TICKET.ID
FROM HD_TICKET
WHERE HD_TICKET.HD_QUEUE_ID in (1)
AND HD_TICKET.IS_PARENT=TRUE
AND HD_TICKET.TITLE not like "CR%"
UPDATE HD_TICKET
SET HD_TICKET.TITLE = CONCAT('CR', ' ', CAST(COUNT(*) + 1 AS CHAR),' ', '-',' ', HD_TICKET.TITLE)
WHERE HD_TICKET.ID in (<TICKET_IDS>)

Running Multiple Sql Commands in a Loop

I successfully executed the sql code below from an msql editor (phpmyadmin), testing it with one customer (where Customer No=1). I need to now run the sql script for all the customers.
START TRANSACTION;
INSERT INTO `addresses` (`AddressLine1`,`CityID`,`ProvStateCode`,`AddressPostCode`,`CountryIso`) SELECT `Bill To Address`,`Bill To City`,`Bill To Province`,`Bill Code`,`Country` FROM `pdx_customers` where `Customer No`=1;
SELECT #last_id := LAST_INSERT_ID();
SELECT `Customer No` FROM `pdx_customers`
INSERT INTO `customer_addresses` (`CustID`,`AddressID`,`AddressTypeID`) Values(1,#last_id,1);
COMMIT;
It seems I would need to create a stored procedure ? In a loop, I need to get the Customer No dynamically for each row in the pdx_customers table, and enter into the Values clause in the insert command, i.e Values(#CustID,#last_id,1). Not sure how I would do this ?
Any help would be appreciated.
Thanks
This is a really common problem, and I would say that doing a loop in sql is almost never a good idea. Here is another option, which you may or may not consider good as it does introduce a new column. I've used it in some apps I've done, and its made things very simple. Does depend on your use case though so it wont be for everyone.
1) Firstly, add a new column to the address table, call it something that wont be confused by anyone looking at the table like TempInsertId.
2) When writing the new address, include the CustomerId in the TempInsertId column
3) Now you can easily read the AddressId and CustomerId back and write it into the CustomerAddress table
4) If you wish, do a final update to set the TempInsertId back to null.
As I said, not advocating in all cases, but it can be a very simple solution to the problem.
You can use the below statement to create a loop:
start transaction;
while counter < max do
insert into . . . ;
set counter=counter+1;
end while;

How to run 'SELECT FOR UPDATE' in Laravel 3 / MySQL

I am trying to execute SELECT ... FOR UPDATE query using Laravel 3:
SELECT * from projects where id = 1 FOR UPDATE;
UPDATE projects SET money = money + 10 where id = 1;
I have tried several things for several hours now:
DB::connection()->pdo->exec($query);
and
DB::query($query)
I have also tried adding START TRANSACTION; ... COMMIT; to the query
and I tried to separate the SELECT from the UPDATE in two different parts like this:
DB::query($select);
DB::query($update);
Sometimes I get 0 rows affected, sometimes I get an error like this one:
SQLSTATE[HY000]: General error: 2014 Cannot execute queries while other unbuffered queries are active. Consider using PDOStatement::fetchAll(). Alternatively, if your code is only ever going to run against mysql, you may enable query buffering by setting the PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute.
SQL: UPDATE `sessions` SET `last_activity` = ?, `data` = ? WHERE `id` = ?
I want to lock the row in order to update sensitive data, using Laravel's database connection.
Thanks.
In case all you need to do is increase money by 10, you don't need to lock the row before update. Simply executing the update query will do the job. The SELECT query will only slow down your script and doesn't help in this case.
UPDATE projects SET money = money + 10 where id = 1;
I would use diferent queries for sure, so you can have control on what you are doing.
I would use a transaction.
If we read this simple explanations, pdo transactions are quite straightforward. They give us this simple but complete example, that ilustrates how everithing is as we should expect (consider $db to be your DB::connection()->pdo).
try {
$db->beginTransaction();
$db->exec("SOME QUERY");
$stmt = $db->prepare("SOME OTHER QUERY?");
$stmt->execute(array($value));
$stmt = $db->prepare("YET ANOTHER QUERY??");
$stmt->execute(array($value2, $value3));
$db->commit();
}
catch(PDOException $ex) {
//Something went wrong rollback!
$db->rollBack();
echo $ex->getMessage();
}
Lets go to your real statements. For the first of them, the SELECT ..., i wouldn't use exec, but query, since as stated here
PDO::exec() does not return results from a SELECT statement. For a
SELECT statement that you only need to issue once during your program,
consider issuing PDO::query(). For a statement that you need to issue
multiple times, prepare a PDOStatement object with PDO::prepare() and
issue the statement with PDOStatement::execute().
And assign its result to some temp variable like
$result= $db->query ($select);
After this execution, i would call $result->fetchAll(), or $result->closeCursor(), since as we can read here
If you do not fetch all of the data in a result set before issuing
your next call to PDO::query(), your call may fail. Call
PDOStatement::closeCursor() to release the database resources
associated with the PDOStatement object before issuing your next call
to PDO::query().
Then you can exec the update
$result= $db->exec($update);
And after all, just in case, i would call again $result->fetchAll(), or $result->closeCursor().
If the aim is
to lock the row in order to update sensitive data, using Laravel's database connection.
Maybe you can use PDO transactions :
DB::connection()->pdo->beginTransaction();
DB::connection()->pdo->commit();
DB::connection()->pdo->rollBack();

MySQL error code: 1175 during UPDATE in MySQL Workbench

I'm trying to update the column visited to give it the value 1. I use MySQL workbench, and I'm writing the statement in the SQL editor from inside the workbench. I'm writing the following command:
UPDATE tablename SET columnname=1;
It gives me the following error:
You are using safe update mode and you tried to update a table without
a WHERE that uses a KEY column To disable safe mode, toggle the option
....
I followed the instructions, and I unchecked the safe update option from the Edit menu then Preferences then SQL Editor. The same error still appear & I'm not able to update this value. Please, tell me what is wrong?
It looks like your MySql session has the safe-updates option set. This means that you can't update or delete records without specifying a key (ex. primary key) in the where clause.
Try:
SET SQL_SAFE_UPDATES = 0;
Or you can modify your query to follow the rule (use primary key in where clause).
Follow the following steps before executing the UPDATE command:
In MySQL Workbench
Go to Edit --> Preferences
Click "SQL Editor" tab and uncheck "Safe Updates" check box
Query --> Reconnect to Server // logout and then login
Now execute your SQL query
p.s., No need to restart the MySQL daemon!
SET SQL_SAFE_UPDATES = 0;
# your code SQL here
SET SQL_SAFE_UPDATES = 1;
SET SQL_SAFE_UPDATES=0;
UPDATE tablename SET columnname=1;
SET SQL_SAFE_UPDATES=1;
No need to set SQL_SAFE_UPDATES to 0, I would really discourage it to do it that way. SAFE_UPDATES is by default on for a REASON. You can drive a car without safety belts and other things if you know what I mean ;)
Just add in the WHERE clause a KEY-value that matches everything like a primary-key comparing to 0, so instead of writing:
UPDATE customers SET countryCode = 'USA'
WHERE country = 'USA'; -- which gives the error, you just write:
UPDATE customers SET countryCode = 'USA'
WHERE (country = 'USA' AND customerNumber <> 0); -- Because customerNumber is a primary key you got no error 1175 any more.
Now you can be assured every record is (ALWAYS) updated as you expect.
Error Code: 1175. You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column To disable safe mode, toggle the option in Preferences -> SQL Editor and reconnect.
Turn OFF "Safe Update Mode" temporary
SET SQL_SAFE_UPDATES = 0;
UPDATE options SET title= 'kiemvieclam24h' WHERE url = 'http://kiemvieclam24h.net';
SET SQL_SAFE_UPDATES = 1;
Turn OFF "Safe Update Mode" forever
Mysql workbench 8.0:
MySQL Workbench => [ Edit ] => [ Preferences ] -> [ SQL Editor ] -> Uncheck "Safe Updates"
Old version can:
MySQL Workbench => [Edit] => [Preferences] => [SQL Queries]
Preferences...
"Safe Updates"...
Restart server
SET SQL_SAFE_UPDATES=0;
OR
Go to Edit --> Preferences
Click SQL Queries tab and uncheck Safe Updates check box
Query --> Reconnect to Server
Now execute your sql query
If you are in a safe mode, you need to provide id in where clause. So something like this should work!
UPDATE tablename SET columnname=1 where id>0
On WorkBench I resolved it By deactivating the safe update mode:
-Edit -> Preferences -> Sql Editor then uncheck Safe update.
The simplest solution is to define the row limit and execute. This is done for safety purposes.
I found the answer. The problem was that I have to precede the table name with the schema name. i.e, the command should be:
UPDATE schemaname.tablename SET columnname=1;
Thanks all.
In the MySQL Workbech version 6.2 don't exits the PreferenceSQLQueriesoptions.
In this case it's possible use: SET SQL_SAFE_UPDATES=0;
Since the question was answered and had nothing to do with safe updates, this might be the wrong place; I'll post just to add information.
I tried to be a good citizen and modified the query to use a temp table of ids that would get updated:
create temporary table ids ( id int )
select id from prime_table where condition = true;
update prime_table set field1 = '' where id in (select id from ids);
Failure. Modified the update to:
update prime_table set field1 = '' where id <> 0 and id in (select id from ids);
That worked. Well golly -- if I am always adding where key <> 0 to get around the safe update check, or even set SQL_SAFE_UPDATE=0, then I've lost the 'check' on my query. I might as well just turn off the option permanently. I suppose it makes deleting and updating a two step process instead of one.. but if you type fast enough and stop thinking about the key being special but rather as just a nuisance..
I too got the same issue but when I off 'safe updates' in Edit ->
Preferences -> SQL Editor -> Safe Updates, still I use to face the
error as "Error code 1175 disable safe mode"
My solution for this error is just given the primary key to the table if not given and update the column using those primary key value.
Eg: UPDATE [table name] SET Empty_Column = 'Value' WHERE
[primary key column name] = value;
True, this is pointless for the most examples. But finally, I came to the following statement and it works fine:
update tablename set column1 = '' where tablename .id = (select id from tablename2 where tablename2.column2 = 'xyz');
This is for Mac, but must be same for other OS except the location of the preferences.
The error we get when we try an unsafe DELETE operation
On the new window, uncheck the option Safe updates
Then close and reopen the connection. No need to restart the service.
Now we are going to try the DELETE again with successful results.
So what is all about this safe updates? It is not an evil thing. This is what MySql says about it.
Using the --safe-updates Option
For beginners, a useful startup option is --safe-updates (or
--i-am-a-dummy, which has the same effect). It is helpful for cases when you might have issued a DELETE FROM tbl_name statement but
forgotten the WHERE clause. Normally, such a statement deletes all
rows from the table. With --safe-updates, you can delete rows only by
specifying the key values that identify them. This helps prevent
accidents.
When you use the --safe-updates option, mysql issues the following
statement when it connects to the MySQL server:
SET sql_safe_updates=1, sql_select_limit=1000, sql_max_join_size=1000000;
It is safe to turn on this option while you deal with production database. Otherwise, you must be very careful not accidentally deleting important data.
just type SET SQL_SAFE_UPDATES = 0; before the delete or update and set to 1 again
SET SQL_SAFE_UPDATES = 1
If you're having this problem in a stored procedure and you aren't able to use the key in the WHERE clause, you can solve this by declaring a variable that will hold the limit of the rows that should be updated and then use it in the update/delete query.
DELIMITER $
CREATE PROCEDURE myProcedure()
BEGIN
DECLARE the_limit INT;
SELECT COUNT(*) INTO the_limit
FROM my_table
WHERE my_column IS NULL;
UPDATE my_table
SET my_column = true
WHERE my_column IS NULL
LIMIT the_limit;
END$
As stated in previous posts, changing the default settings of the database server will result in undesired modification of existing data due to an incorrect query on the data in a published project. Therefore, to implement such commands as stated in previous posts, it is necessary to run them in a test environment on sample data and then execute them after testing them correctly.
My suggestion is to write a WHERE conditional statement that will loop through all the rows in all conditions if an update should work for all rows in a table. For example, if the table contains an ID value, the condition ID > 0 can be used to select all rows:
/**
* For successful result, "id" column must be "Not Null (NN)" and defined in
* INT data type. In addition, the "id" column in the table must have PK, UQ
* and AI attributes.
*/
UPDATE schema_name.table_name
SET first_column_name = first_value, second_column_name = second_value, ...
WHERE id > 0;
If the table does not contain an id column, the update operation can be run on all rows by checking a column that cannot be null:
/**
* "first_column_name" column must be "Not Null (NN)" for successful result.
*/
UPDATE schema_name.table_name
SET first_column_name = first_value, second_column_name = second_value, ...
WHERE table_name.first_column_name IS NOT NULL;
MySql workbench gave me the same error, after I unchecked safe mode , I then reconnected the server and the update function worked.
Go to Query in the menu bar and reconnect the server
Query Menu -> Reconnect to Server
You can enable and disable safe update option by following commands.
To Disable,
SET SQL_SAFE_UPDATES=0;
or
SET SQL_SAFE_UPDATES=OFF;
To Enable,
SET SQL_SAFE_UPDATES=1;
or
SET SQL_SAFE_UPDATES=ON;
First:
Please make sure you want to update all records in that table because without the where clause it is dangerous to update all records in that table. It's rare time you want to update all records in the table.
most of the time you want to update specific records which should include where cluase if again you want to update all records open MySQL workbench> Edit> Preference>SQL Editor > scroll down at right and uncheck the "Safe Updates(rejects UPDATEs and DELETEs with no restrictions)".
It is for safe updates.
If you uncheck the above said then there are chances that you update all records instead of one record which leads to a database backup restore. there is no rollback.
I've just added COMMIT; in the end
You can enable and disable safe update option by following commands.
SET SQL_SAFE_UPDATES=1;

Avoid MySQL multi-results from SP with Execute

i have an SP like
BEGIN
DECLARE ...
CREATE TEMPORARY TABLE tmptbl_found (...);
PREPARE find FROM" INSERT INTO tmptbl_found
(SELECT userid FROM
(
SELECT userid FROM Soul
WHERE
.?.?.
ORDER BY
.?.?.
) AS left_tbl
LEFT JOIN
Contact
ON userid = Contact.userid
WHERE Contact.userid IS NULL LIMIT ?)
";
DECLARE iter CURSOR FOR SELECT userid, ... FROM Soul ...;
...
l:LOOP
FETCH iter INTO u_id, ...;
...
EXECUTE find USING ...,. . .,u_id,...;
...
END LOOP;
...
END//
and it gives multi-results. Besides it's inconvenient, if i get all this multi-results (which i really don't need at all), about 5 (limit's param) for each of the hundreds of thousands of records in Soul, i'm afraid it will take all my memory (and all in vain).
Also, i noticed, if i do prepare from an empty string, it still has multi-results...
At least how to get rid of them in the execute statement?
And i would like to have a recipe to avoid ANY output from SP, for any possible statement
(i also have a lot of "update ..."s and "select ... into "s inside, if they can produce multi's).
Tnx for any help...
Well. I'll just say that it has come out that there wasn't really a problem. I didn't investigate hard, but it looks like the server didn't actually try to execute the statement ("call Proc();") to see whether there will be any results to return - it just looked at the code and assumed that there will be multiple result sets, requiring connection to be capable of handling them. But in PhpMyAdmin, which i was using at the time, it wasn't. However, issuing the same command from the MySQL command line client did the trick - no complaining about the given connection context, and no multis, too, because they don't have to be there - it's just a MySQL's estimation. I didn't have to conclude from the error, that the SP like this one will certainly return multis in MySQL, flushing all the intermediately fetched data, which i will need to suppress somehow.
It may be not so as i supposed, but the problem is gone now.