I have a big problem when I want to make a view.
CREATE VIEW AnneeBillet (ANNEE_BILLETS, CHIFFRES)
AS SELECT YEAR(FIN_RESERVATION), sum(TYPE.PRIX*NOMBRE)
FROM TYPE, BILLET
where TYPE.TYPE = BILLET.TYPE;
I have this error :
In aggregated query without GROUP BY, expression #1 of SELECT list
contains nonaggregated column 'parc.BILLET.FIN_RESERVATION'; this is
incompatible with sql_mode=only_full_group_by
I have already tried many solutions like putting
SET GLOBAL sql_mode=(SELECT REPLACE(##sql_mode,'ONLY_FULL_GROUP_BY',''));
But I'm with a docker container and I've seen that I had to modify directly the configuration file to have what I want.
Then, I found this post on stackoverflow but I can't do
--sql_mode=(SELECT REPLACE(##sql_mode,'ONLY_FULL_GROUP_BY',''))
in my docker-compose because I have an error like this :
mysql_1 | 2021-04-27T07:59:53.283400Z 0 [ERROR] [MY-000077]
[Server] /usr/sbin/mysqld: Error while setting value '(SELECT
REPLACE(##sql_mode,'ONLY_FULL_GROUP_BY',''))' to 'sql_mode'.
Please help me, I'm fed up with this problem.
Just add GROUP BY YEAR(FIN_RESERVATION) to the end of your query or change it to MIN(YEAR(FIN_RESERVATION)) - you can also use max. If you didn't do these things and instead changed the mode MySQL would simply arbitrarily pick one of the year values anyway
Only full group by is a good thing
If you permanently want to disable only_full_group_by on startup, you can add:
sql-mode= "STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION"
To your my.ini or my.cnf under '[mysqld]'.
Also if you get the error:
"Error while setting value 'STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION' to 'sql_mode'"
as I did, you can get around this issue, by first clearing all sql-modes by putting sql-mode="" above:
sql-mode= "STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION"
You can't use an sql expression as the value of --sql_mode. Run SET SESSION sql_mode=(SELECT REPLACE(##sql_mode,'ONLY_FULL_GROUP_BY','')); SELECT ##sql_mode; in your server and use the value it shows with --sql_mode.
My intention was to run this query in mysql:
update my_users set isLocked=1 where categoryId=10;
But I accidentally typed a dash (-) instead of the equal sign(=). So the query looked like this:
update my_users set isLocked=1 where categoryId-10;
This produce issues because it ran for everybody instead of just that belong to the category 10
Wondering why the 2nd call do not produce any errors and prevent the execution ?
Yup . . . You have an arithmetic expression, which is interpreted as:
categoryId - 10 <> 0
So, it doesn't update all rows -- just all rows where categoryId is not 10.
Ooops. This is a consequence of MySQL helping you by treating booleans as interchangeable with integers, with 0 for false and all other values for true.
You might be able to prevent this using sql_safe_updates mode. However, I'm not sure if the mode actually checks that you make an explicit comparison on the key.
why do the following queries work on Maria DB (10.1.9)...
SET SESSION wait_timeout = 28000;
SET SESSION wait_timeout = ##wait_timeout;
SELECT GREATEST(28000, ##wait_timeout);
... but that one not?
SET SESSION wait_timeout = GREATEST(28000, ##wait_timeout)
It throws a type error:
#1232 - Incorrect argument type to variable 'wait_timeout`
Allthough this error can be resolved by replacing #wait_timeout with CAST(##wait_timeout AS INT) or CONVERT(##wait_timeout, SIGNED) (the latter works on MySQL as well) to the query I wonder why the second and third query work.
What's going on here? It can't be the GREATEST operation because query 3 works and it can't be a differing variable type because the (implicit) conversion would fail in query 2 (it should have the same type anyhow). The same thing happens with other system variables as well.
By the way: The same query works under MySQL (tried it in a SQLfiddle with MySQL version 5.6) so this is an inconsistency between MariaDB and MySQL.
Any help appreciated!
As some have guessed correctly: it's a bug (now confirmed) that was introduced recently.
For more details have a look at the mariadb issue tracker:
https://jira.mariadb.org/browse/MDEV-9516
Update (2016-03-21)
Regarding the bugtracker the problem seems fixed in 10.1.13.
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;
I have an instance of MySQL 5.0.4.1 with an application written in Hibernate. On one of the pages, I get the following error message in the server log:
Unknown character set index for field '123' received from server.at com.mysql.jdbc.Connection.getCharsetNameForIndex(Connection.java:1664)at com.mysql.jdbc.Field.(Field.java:144)at com.mysql.jdbc.MysqlIO.unpackField(MysqlIO.java:506)at com.mysql.jdbc.MysqlIO.getResultSet(MysqlIO.java:280)at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1319)at com.mysql.jdbc.MysqlIO.sqlQuery(MysqlIO.java:1218)at com.mysql.jdbc.Connection.execSQL(Connection.java:2233)at com.mysql.jdbc.Connection.execSQL(Connection.java:2193)at com.mysql.jdbc.Connection.execSQL(Connection.java:2174)at com.mysql.jdbc.Connection.setAutoCommit(Connection.java:536)at org.apache.commons.dbcp.DelegatingConnection.setAutoCommit(DelegatingConnection.java:268)at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.setAutoCommit(PoolingDataSource.java:293)at org.hibernate.transaction.JDBCTransaction.toggleAutoCommit(JDBCTransaction.java:194)at org.hibernate.transaction.JDBCTransaction.rollbackAndResetAutoCommit(JDBCTransaction.java:186)at org.hibernate.transaction.JDBCTransaction.rollback(JDBCTransaction.java:162)at org.springframework.orm.hibernate3.HibernateTransactionManager.doRollback(HibernateTransactionManager.java:603)at org.springframework.transaction.support.AbstractPlatformTransactionManager.processRollback(AbstractPlatformTransactionManager.java:579)at org.springframework.transaction.support.AbstractPlatformTransactionManager.rollback(AbstractPlatformTransactionManager.java:556)at org.springframework.transaction.interceptor.TransactionAspectSupport.doCloseTransactionAfterThrowing(TransactionAspectSupport.java:284)at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:100)at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:170)at org.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor.invoke(MethodSecurityInterceptor.java:66)at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:170)at org.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor.invoke(MethodSecurityInterceptor.java:66)at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:170)at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:176)at $Proxy6.getDataFromDatabase(Unknown Source)at org.myCompany.myAction.load(Unknown Source)at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)at java.lang.reflect.Method.invoke(Method.java:324)at org.apache.struts.actions.DispatchAction.dispatchMethod(DispatchAction.java:274)at org.apache.struts.actions.DispatchAction.execute(DispatchAction.java:194)at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)at javax.servlet.http.HttpServlet.service(HttpServlet.java:787)at javax.servlet.http.HttpServlet.service(HttpServlet.java:908)at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217)at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:213)at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:280)at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:509)at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:218)at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:509)at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:209)at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:509)at com.iplanet.ias.web.connector.nsapi.NSAPIProcessor.process(NSAPIProcessor.java:157)at com.iplanet.ias.web.WebContainer.service(WebContainer.java:579)
This error occurs on a production environment so I don't know which query produced the problem, but I do know that none of my tables has a column named '123'. Do you have any suggestions about what might be causing this problem?
Edit: As a followup, I found that this behavior is a known bug in MySQL 5.0.4, but I haven't found a good wokaround since I don't have the option of upgrading mySQL.
Could be that somehow the character set for the field has been set to an invalid value, run this SQL on the server with the problem replacing the table name and the column 'Collation' will show the characterset for each varchar/char fields
SHOW FULL COLUMNS IN table_name;
You can then change the character set of a field by using the following:
ALTER TABLE t MODIFY col1 VARCHAR(50) CHARACTER SET latin1;
Internally, MySQL is mapping out the indexes across the columns. Normally this is done using integers that represent the column index. Most indexes are actually a compound index once built (col 1 + col 3) which form something like field 13.
Likely this happened when migrating data from dev into production when the stack is not an exact replica.
As 3urdoch mentioned you can pull the charset using internal MySQL function; and then change the table's charset to a compatible encoding.
Alternatively (where I'm willing to bet this issue came from) you can check if the loaded driver for the Production matches the loaded driver for the Other server. This will prevent re-occurring issue if the Development/Other server is still being used for testing, and migrated into Production.