I'm moving a database from MySQL to MariaDB, and testing export/import. One issue that's come up consistent is when a table has virtual columns. SHOW CREATE TABLE in MySQL returns this:
CREATE TABLE `table1` (
`colA` varchar(50) NOT NULL,
`colB' varchar(50) NOT NULL,
'vir1` GENERATED ALWAYS AS (concat_ws(' ', `colA`, `colB`)) VIRTUAL NOT NULL,
`colC` varchar(50) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
MariaDB then reports an error when importing it:
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'NOT NULL,
`colC` varchar(50) DEFAULT NULL
The problem appears to be in the "VIRTUAL NOT NULL" part of the virtual column definition. If I edit the import sql file by hand, to this:
CREATE TABLE `table1` (
`colA` varchar(50) NOT NULL,
`colB' varchar(50) NOT NULL,
'vir1` GENERATED ALWAYS AS (concat_ws(' ', `colA`, `colB`)) VIRTUAL,
`colC` varchar(50) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
then it imports just fine, so I guess MariaDB doesn't like being told whether a virtual field is allowed to be null or not (which seems logical, since it wouldn't know whether the inputs are null or not), but the exported MySQL file always has either VIRTUAL NULL or VIRTUAL NOT NULL as part of the exported table definitions.
Is there a way to avoid this? I could grep through the exported file to s&r those definitions, but that seems kludgey and at risk of running into other issues later if it's a compatibility issue with a known solution.
The syntax you show works in MySQL, I just tested with MySQL 5.7 and it does not cause an error.
The MariaDB syntax is not compatible. This has been reported as a bug: https://jira.mariadb.org/browse/MDEV-10964
You could vote for that bug, or even contribute a patch to resolve it.
The bottom line is that MariaDB forked from MySQL in 2010, and the two products have been growing further and further apart ever since then. They should no longer be considered compatible.
Just like if you were to migrate from a MySQL database to PostgreSQL or Microsoft SQL Server, there will be some edits needed to make MySQL syntax work on different brands of RDBMS.
The problem is that null / not null is a part of mysql's definition of generated columns, therefore mysqldump exports these properties as part of dumping the table structures. This is the right thing to do as mysqldump is designed to work with mysql and not with mariadb.
You should use a proper ETL tool for migrating data between different database products, even if those pruducts are as closely related to each other as mysql and mariadb are.
I've seen several posts about MySQL error #1210 but I haven't noticed one about errors occurring within phpMyAdmin. Perhaps someone can help.
Using phpMyAdmin, I fill in the GUI form to (for example) drop an obsolete field in an existing table in an existing database. It asks me to confirm that I want to drop the field, and then fails with an error "#1210 - Incorrect arguments to DATA DIRECTORY". There's none of my coding in here, no MySQL queries of mine, just a few boxes ticked and buttons pressed, yet phpMyAdmin gives an error. I get this error with any attempt to alter a table structure.
For this particular job, the table was created with the following (which was generated by an Export from another phpMyAdmin installation)...
CREATE TABLE `choreovote` (
`id` int(11) NOT NULL,
`compyear` year(4) NOT NULL,
`competition` year(4) NOT NULL,
`memberno` smallint(5) UNSIGNED NOT NULL,
`entry_id` int(11) NOT NULL,
`votes` smallint(5) UNSIGNED NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1 DATA DIRECTORY='./cloggb_db/' INDEX DIRECTORY='./cloggb_db/';
ALTER TABLE `choreovote` ADD PRIMARY KEY (`id`);
ALTER TABLE `choreovote` MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;
COMMIT;
And the phpMyAdmin generated query which is not working is...
ALTER TABLE choreovote DROP compyear;
Does anyone have any idea where I should look?
Many thanks!
I'm testing this on my system, and working off of some hints at DATA DIRECTORY MySQL, I was able to make it work after:
changing to a full path outside the existing MySQL data directory,
creating the intended directory outside of MySQL (in my case, I have shell access and just used mkdir), and
changing permission on the folder such that my MySQL user had permissions to access the folder and create new files.
Once I did all three of those, your SQL query ran successfully.
Installing Mura on a brand new machine and local MySQL 5.7 database. Per the install instructions I browse to the Mura index.cfm file to complete the installation. I enter in the database and DSN info. After a few seconds I get an error message.
Error Executing Database Query.
Datasource: muracms
SQL: CREATE TABLE
IF NOT EXISTS tuserremotesessions ( userID char(35) default NULL,
authToken char(32) default NULL, data text, created datetime
default NULL, lastAccessed datetime default NULL, PRIMARY KEY
(userID) )
Code: 42000
Type: 42000
All parts of a PRIMARY KEY must be NOT NULL; if you need NULL in a key, use UNIQUE instead
Refreshing browser page results in this error again. I can see that tables have already been created in the database. I have been unsuccessful at attempts to internet search for a solution.
Does anyone have an idea of what I can do to get past this error? I have successfully installed Mura on other servers before so I'm really stumped.
For those who run into this error, it is due to a change in MySql 5.7 from how MySql 5.6 worked. See http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-3.html. Specifically
Columns in a PRIMARY KEY must be NOT NULL, but if declared explicitly
as NULL produced no error. Now an error occurs. For example, a
statement such as CREATE TABLE t (i INT NULL PRIMARY KEY) is rejected.
I edited the create table statements for several tables in {murahome}/requirements/mura/dbUpdates/5.2.0.cfm to remove the default NULL statement on two tables and then everything worked fine.
I have a problem. When I try to edit something in the category area of my opencart isntallation an error shows up saying the table category_path does not exist.
This error usually happens when an upgrade went wrong. Can I simply use a CREATE_TABLE query in my phpmyadmin to fix this, or would that not work?
Hope someone can help me with this.
If you only need to create the category path table it can be created like this (replacing oc_ with your database prefix if necessary):
CREATE TABLE `oc_category_path` (
`category_id` int(11) NOT NULL,
`path_id` int(11) NOT NULL,
`level` int(11) NOT NULL,
PRIMARY KEY (`category_id`,`path_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci;
You can run that SQL from phpMyAdmin or any other MySQL client. Afterward you can navigate to the Admin > Catalog > Category and click Repair which should generate the necessary records.
Please note, that table is generated by install/upgrade script and it's exactly as you say, probably a botched database upgrade or none at all. If that's the case, bear in mind that you may have other database problems as well and you may benefit by running the upgrade script on your database.
I'm having troubles with a certain query on one of my servers. On all other places I've tested it it works completely fine but on the server i want to use it it isn't working.
It's about the following SQL:
SELECT facturen.id AS fid,
projecten.id AS pid,
titel,
facturen.totaal_bedrag AS totaal,
betaald,
datum
FROM facturen,
projecten
WHERE facturen.project_id = projecten.id
AND projecten.eigenaar = '1'
ORDER BY datum DESC
This is the error code I get from it:
SELECT command denied to user 'marco'#'localhost' for table 'projecten'
The tables:
facturen:
CREATE TABLE IF NOT EXISTS `facturen` (
`id` int(11) NOT NULL auto_increment,
`project_id` int(11) NOT NULL,
`datum` int(11) NOT NULL,
`lever_datum` int(11) NOT NULL,
`totaal_bedrag` decimal(9,2) NOT NULL,
`btw` decimal(9,2) NOT NULL,
`bedrijf` varchar(40) NOT NULL,
`contactpersoon` varchar(60) NOT NULL,
`adres` varchar(60) NOT NULL,
`postcode` varchar(7) NOT NULL,
`plaats` varchar(30) NOT NULL,
`betaald` int(11) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=201200006 ;
projecten:
CREATE TABLE IF NOT EXISTS `projecten` (
`id` int(11) NOT NULL auto_increment,
`titel` varchar(80) NOT NULL,
`eigenaar` int(11) NOT NULL,
`creatie_datum` int(11) NOT NULL,
`eind_datum` int(11) NOT NULL,
`totaal_bedrag` decimal(9,2) NOT NULL,
`btw` decimal(9,2) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=201200004 ;
The strange part is that every other query on both the 'projecten' table and the 'facturen' table works completely fine, also this query works fine on two other servers of mine.
I faced the same situation but its funny that reason for the error was due to the use of the incorrect database or schema name.
Its true that multiple issues can lead to error you have mentioned.
You need to grant SELECT permissions to the MySQL user who is connecting to MySQL
same question as here Error: select command denied to user '<userid>'#'<ip-address>' for table '<table-name>'
see answers of the link ;)
This error also arises for a syntax error occurred due to tablename aliasing.
For instance, when executing below query,
select * from a.table1, b.table2 where a.table1= b.table2
below error occurs:
MySQL Error: #1142. Response form the database. SELECT command denied to user "username#ip" for table "table1"
Solution : Syntax to alias tablename should be used properly, syntax solution for above instance:
select * from table1 a, table2 b where a.table1= b.table2
I had this problem too and for me, the problem was that I moved to a new server and the database I was trying to connect to with my PHP code changed from "my_Database" to "my_database".
This is th privileges issue in your database users. first check and grant permission to user
'marco' in localhost
I just emptied my session data then it worked again. Here is where you find the button:
So the issue I ran into was this... the application I used to grant the permissions converted the Schema.TableName into a single DB statement in the wrong table, so the grant was indeed wrong, but looked correct when we did a SHOW GRANTS FOR UserName if you weren't paying very close attention to GRANT SELECT vs GRANT TABLE SELECT. Manually correcting the Grant Select on Table w/ proper escaping of Schema.Table solved my issue.
May be unrelated, but I can imagine if one client does this wrong, another might too.
Hope that's helpful.
I run into this problem as well, the case with me was incorrect naming . I was migrating from local server to online server.
my SQL command had "database.tablename.column" structure. the name of database in online server was different. for example my code was "pet.item.name" while it needed to be "pet_app.item.name"
changing database name solved my problem.
This error happened on my server when I imported a view with an invalid definer.
Removing the faulty view fixed the error.
The error message didn't say anything about the view in question, but was "complaining" about one of the tables, that was used in the view.
You need to give privileges to the particular user by giving the command mysql> GRANT ALL PRIVILEGES . To 'username'#'localhost'; and then give FLUSH PRIVILEGES; command.
Then it won't give this error.., hope it helps thank you..!
If you using/connect more then one databases then you should use same DB_USERNAME for all databases
I had the same issue solved by using same DB_USERNAME for all databases ,
because i was use/connect multiple databases in same project and every database DB_USERNAME was different so when i run the query select,update, delete etc from multiple database then was get this error.
because if you use more then one table in query and the database DB_USERNAME is different you will get this error.
I had this error, because I copied stored procedure from localhost and there the db name was different then on the server I wanted to use it. It took me a couple of hours to figure out, why I don't have permissions to execute the procedure... Check you db names pls :D Hope someone finds this useful...
I tried to issue SELECT * FROM information_schema.INNODB_METRICS; on a so-called "budget host." I got 1142 because reading that particular system table requires the PROCESS privilege and the user didn't have it. I had to fool around to figure out it was PROCESS and not some other privilege that was missing.
(No, the "budget host" won't grant that priv to the user. They probably don't want their customers to see how ridiculously overloaded their servers are. Because MySQL licenses are expens .... wait, no they're free.)
In MySQL query browser go to Tools tab>MySQL Administrator > User Administration and then give the privileges to user.