I have a query like this
UPDATE `database`.`user`
SET `Password`=Password("test1234!##$")
WHERE `UserID`='1234';
I ran this once and it updated the Password fine. I changed the case of the t in test and it started to fail with the message
Error Code: 1146. Table 'database.Unknown' doesn't exist.
After some experimentation I found that removing the $ in the string allowed the query to run successfully. I attempted to escape the character with / but the error still occurred. The collation on the column is utf8 and it is varchar(50).
The query itself is being executed in MySQL Workbench 5.2.47 and on MySQL version 5.1.62 Community Edition.
Can anyone enlighten me on why the $ is being troublesome.
EDIT: It is now occurring without any of the special characters. I also am aware there are much safer ways of hashing passwords. I am just curious at this point why the specific error is occurring.
First deduct the issue is from workbench:
Log in from command prompt (mysql -u Username -pPassword -h hostname) or with phpmyadmin and then try executing the query.
If that works, it's the workbench.
Then you might first want to just delete all configured connection settings in the workbench and re-adding them. This might already solve your problem.
If the problem maintains, you can try to re-install workbench.
Ended up being that a trigger existed that had this in it
INSERT INTO Unknown VALUES(1);
I don't know what the purpose of this is but it obviously was causing the issue. Thanks for the help regardless everyone.
Related
I'm running an Ubuntu Server with MySQL in VirtualBox and trying to change the password for a user.
I run:
sudo mysql -u root -p
to access MySQL. At this point, and with any other commands not trying to see a user's password, everything is working.
In MySQL ( ) I run:
SELECT * FROM mysql.user;
After I run this, the entire display and terminal change. The output and command line are both displaying strange characters. I run this command which works just fine. What gives?
SELECT user FROM mysql.user;
Here are the before and after screen shots:
Screen Shot Before,
Screen Shot After
Any help would be greatly appreciated. I have no clue why this is happening. Is this an Ubuntu thing, a MySQL thing or a VirtualBox thing? I'm a noob so this is just an uninformed theory but could it have something to do with MySQL authenticated_string and something to do with hashing?
It actually creates a change that persists even upon typing exit and hitting Enter, exiting MySQL and back to the Ubuntu command line where the weird characters are still showing.
EDIT:
I was following a blog tutorial and inserted <db-password> as the password when creating the MySQL user. I was supposed to insert an actual new password instead but figured I'd just use that. Are the <, - or > characters that I used when setting the user's MySQL password maybe causing this?
I believe this was a character encoding issue in MySQL because SELECT * FROM mysql.user WHERE user = 'root'; doesn't have the same issue. Because of that, I believe the issue only occurs at that one user's password data point where the <, - and > characters were used. Maybe someone else can provide a better answer explaining more thoroughly why this occurs. Specifically, I'm curious as to how this issue in MySQL is then able to affect the appearance of the Ubuntu Command Line once the MySQL shell is exited.
I'm having an issue with replication for two Mysql servers. The master is running Mysql 5.6 and the slave is running Mysql 8.0 due to another dependency that requires at least version 8. I am only replicating one DB, for this example's sake 'my_db'. However at a certain point in the day the master runs backups and tries to update the DB 'my_db_backups'. I am not replicating this DB and I just want to ignore these SQL commands on the replica. I explicitly ignore this database in my mysql.conf file using:
replicate-ignore-db=my_db_backups
However when I restart the mysql server I continue to see an error:
Last_SQL_Errno: 1049
Last_SQL_Error: Error 'Unknown database 'my_db_backups'' on query. Default database: 'my_db'. Query: 'INSERT INTO my_db.`table_1` SELECT * FROM my_db_backups.`2021_01_04_17_36_22_table_1`'
Everything I've read seems to indicate that setting replicate-do-db should only execute queries related to that DB. Additionally adding an explicit ignore, replicate-ignore-db, I would expect to work as well but I'm having no luck.
My full mysql.conf looks like this:
[mysqld]
server-id=20
lower_case_table_names=1
updatable_views_with_limit=1
relay-log-index=slave-relay-bin.index
relay-log=slave-relay-bin
replicate-ignore-db=my_db_backups
replicate-ignore-table=my_db.mysql_8_incompatible_view_1
replicate-ignore-table=my_db.mysql_8_incompatible_view_2
replicate-ignore-table=my_db.mysql_8_incompatible_view_3
replicate-ignore-table=my_db.mysql_8_incompatible_view_4
replicate-wild-do-table=my_db.%
replicate-do-db=my_db
I have tried every combination of these replicate-do and replicate-ignore-do configurations that I can think of I've tried adding:
replicate-wild-ignore-table=my_db_backups.%
and removing:
replicate-ignore-db=my_db_backups
and I've tried putting them both in the conf file. Nothing seems to work.
I know that I can explicitly skip error 1049 which is what I may have to end up doing. I'm just pulling my hair out trying to figure out why the other configurations aren't having any effect and can't let it go.
Any help would be greatly appreciated!
I noticed that the statement that produces the error isn't actually writing to a table in my_db_backups. It's replicating an INSERT to a table in my_db.
INSERT INTO my_db.`table_1` SELECT * FROM my_db_backups.`2021_01_04_17_36_22_table_1`
The statement is reading from a table in my_db_backups, which it did not find on the replica.
So the statement that inserts into my_db.table_1 will be executed on the replica, because the default database my_db was not ignored.
You could also fix this by using ROW-based binary logs on the master, so it doesn't matter that it's reading from a table that doesn't exist on the replica. The INSERT would result in a row image on the master, where the table does exist.
I run a web application on a shared LiteSpeed server with Mariadb version 10.3.22. I do have access to a terminal.
Cron is set up to perform a daily mysqldump, but I now get the error message:
mysqldump: Error 1412: Table definition has changed, please retry transaction when dumping table `TABLENAME` at row: 0
I do get a sql file, but it is a little smaller than it used to be. The table that is claimed to have changed it's definition is empty, just as it use to be (as far as I know).
I do not know much about mysql, and I do not understand the message "retry transaction when dumping table TABLENAME at row: 0"
Any clues about how to deal with that?
Please check the general log file of mysql service has "TRUNCATE" command on the table or not.
"TRUNCATE" command on the table during the mysqldump process changes table information and changing the command to "DELETE" command solved issue to me.
Default location of general log file is "/var/log/mysql/mysql.log" but it could be changed by "general_log_file" option and "general_log" option on "my.cnf" file.
If you are using mysql and getting error of "table defination has changed, please retry transaction " you have to do only one thing that is reconnect to DBMS, it will definitely solve the problem , tere is a button of "reconnect to DBMS" at home Page.
I'm hoping this is a simple question. I recently installed MySQL Workbench, and thought everything was going fine, until I noticed the output of messages at the bottom. They're in a foreign language. See attached screenshot. I tried the same queries in phpMyAdmin and get similar results.
Server connection collation: utf8mb4_general_ci (I tried to change to utf8_general_ci but it won't let me)
Any help is greatly appreciated.
Try changing your my.ini file to the following:
lc-messages=en_US
or run the command prompt and in the mysql prompt do:
SET lc_messages = 'en_US';
Check the following reference
I have a stored procedure that works in the mysql> terminal, but when I try to run it through my application it doesn't work.
I don't get any error messages or anything.
If I try to execute the sp through MySql Query Browser the response is simply :
"Query canceled."
This particular SP is just a simple update command, but I have other SP that are SELECT commands and they work.
Ive tried changing the DEFINER to '%' and '' but neither of that worked.
I'm thinking this has to be some kind of a permission problem or a my.cnf problem but I have no idea how to fix this nor do I seem to be able to find a solution on the internet machine :)
EDIT: I just tried to execute it from phpmyadmin and that worked. I tried both as root and myUser. What is going on ?
If you can run select based stored procedures, and not the update one, the user you are connecting with query browser has insufficient privileges on some tables or columns updated by the stored procedure. You can check that with the user manager.
Obs: your_user#localhost seems to be ok as you can run with phpmyadmin but with query browser, the user is your_user#%.