I'm trying to move data from a MySQL database (5.6.32-78) to an Oracle Database (11g). Using mysqldump, the output causes a "missing right parenthesis" error when creating a table in oracle. ie...
mysqldump output:
CREATE TABLE "table1" (
"ID" int(11) NOT NULL,
"column1" int(11) NOT NULL DEFAULT '0',
"column2" varchar(255) NOT NULL DEFAULT '',
PRIMARY KEY ("ID")
);
Oracle is expecting the following (the order of NOT NULL and DEFAULT switched):
CREATE TABLE "table1" (
"ID" int(11) NOT NULL,
"column1" int(11) DEFAULT '0' NOT NULL,
"column2" varchar(255) DEFAULT '' NOT NULL,
PRIMARY KEY ("ID")
);
Is there an option I'm missing to correct this? I have a couple hundred tables to move and do not want to "reinvent the wheel" by writing procedure to get the correct output.
(--compatible=oracle does not make any difference).
Thanks.
Doug
I'll try to make the question more specific.
I am trying to migrate a MySQL to Oracle database and tried using mysqldump and various options, but it does not generate an Oracle usable output. I can't use Oracle's SQL Developer because it requires connecting to both the MySQL database (internet) and Oracle database (inside of a "no internet access" firewall) at the same time. Is anyone aware of a way to create an Oracle friendly export of a MySQL database?
The order of NOT NULL and DEFAULT is only one problem you'll face. There are many differences between MySQL and Oracle that cannot be fixed with mysqldump options.
http://dev.mysql.com/doc/refman/5.7/en/mysqldump.html#option_mysqldump_compatible says:
This option does not guarantee compatibility with other servers. It only enables those SQL mode values that are currently available for making dump output more compatible. For example, --compatible=oracle does not map data types to Oracle types or use Oracle comment syntax.
So you would have to do some hand-editing of your dump file before importing it to Oracle.
You're better off using Oracle SQL Developer to migrate your MySQL database to Oracle. You can find a step-by-step guide with videos here: http://www.oracle.com/technetwork/database/migration/index.html
Note the steps for MySQL can be found by clicking the link "and others..." below the list of other commercial RDBMS products. Here's a direct link: http://www.oracle.com/technetwork/database/migration/mysql-093223.html
Related
I have a largish (4GB) database, that I would like to dump, but when using the mysqldump tool (the MariaDB version, Ver 10.19 Distrib 10.4.21-MariaDB, for Linux (x86_64)), my dumping process has always failed at the same table, with the not so helpful error message:
mysqldump: Couldn't execute 'SHOW CREATE TABLE `AffiliateProgramsCampaigns`': Lost connection to MySQL server during query (2013)
I've tried to debug this error, but none of the obvious solutions worked for me, so I did a little experimenting, and found the culprit of my problem. The table in question, contains a VIRTUAL column, which strangely, if I remove, the dump finishes succesfully. I've digged a little more, but found no such error anywhere else relating to dumping MariaDB databases with virtual columns. Adding the --verbose option to the dump, is not helping either, as it gives me no other significant information.
As the query fails at the SHOW CREATE TABLE part, I've figured it has something to do with the structure of the CREATE TABLE query, but when I only try to dump the structure of this database, everything works like a charm. So I am stuck at the moment, trying to solve this issue. I could give up on the virtual column in this specific table, but if there would be any alternative, even a different dump tool, I would more likely go with that solution. Any advice, on how to fix this, or at least how to debug the problem more throughly would be appreciated!
Here are some other debug informations, that could be helpful:
This is the end of the --verbose dump output:
-- Retrieving view structure for table ActionLogReferences...
-- It's base table, skipped
-- Retrieving view structure for table ActionLogs...
-- It's base table, skipped
-- Retrieving view structure for table AffiliatePrograms...
-- It's base table, skipped
-- Retrieving view structure for table AffiliateProgramsCampaigns...
mysqldump: Couldn't execute 'SHOW CREATE TABLE `AffiliateProgramsCampaigns`': Lost connection to MySQL server during query (2013)
And here is the CREATE TABLE syntax for the table in question:
CREATE TABLE `AffiliateProgramsCampaigns` (
`AffiliateProgramsCampaignId` bigint(20) NOT NULL AUTO_INCREMENT,
`Name` varchar(255) NOT NULL,
`Description` tinytext NOT NULL,
`StartDate` datetime NOT NULL,
`EndDate` datetime NOT NULL,
`IsActivated` tinyint(1) NOT NULL DEFAULT 0 COMMENT 'This column shows if this campaign was manually activated.',
`Status` tinyint(4) GENERATED ALWAYS AS (if(`IsActivated`,if(curdate() between `StartDate` and `EndDate`,1,0),0)) VIRTUAL COMMENT 'The final, computed status of the campaign. When querying, you should use this to check the status.',
`affiliatePrograms_AffiliateProgramId` mediumint(9) NOT NULL,
`images_ImageId_BaseImage` bigint(20) DEFAULT NULL COMMENT 'The id of the base image.',
`images_ImageId_CoverImage` bigint(20) DEFAULT NULL COMMENT 'The id of the cover image.',
PRIMARY KEY (`AffiliateProgramsCampaignId`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1
The query that is reported by mysqldump btw runs every single time I try it, both from phpymadmin and from the command line mysql interface. I also tried dumping with different users, even with the root user, but I always get the same error, at the same spot.
The problem was with the CURDATE() function that was used in the virtual column. By changing the function, to CURRENT_TIMESTAMP(), the issue is solved.
Also posted a bug report on the official boards: https://jira.mariadb.org/browse/MDEV-26619
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 know this question has been asked before but I still couldn't get it fixed. I'm getting a #1046 error while importing my WP database from local to server. Here is what I get :
CREATE TABLE `wp_cntctfrm_field` (
`id` int(11) NOT NULL,
`name` char(100) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8
MySQL a répondu (Translation: MYSQL responded) : Documentation
1046 - Aucune base n'a été sélectionnée(translation : no database was selected)
It's the first time I do it so I followed a tutorial but nothing seems to make it work.
You must select the target database you want to use to create/populate the database schema in.
You can select the target database at a global level for instance with Mysql Workbench in the left side, right hand click on the database you want to populate and select "Set as default schema".
You can also define the target database upon each SQL query.
For instance with your example, if the target database is named targetdb :
CREATE TABLE targetdb.wp_cntctfrm_field ( id int(11) NOT NULL, name char(100) NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8
Please note that the target database must be created first with the appropriate CREATE DATABASE clause.
Hope this helps
You can use mysql -u <user> <DB_name> <<filename>
or add use <db_name>; at top of your dump file
I am rolling back to MySQL GUI Tools' MySQL Query Browser since I can't find the shortcut to get a table's creation script in MySQL Workbench.
I cannot find such an option either, at least in the Community edition.
I suppose this corresponds to the Reverse Engineering feature, which, unfortunately, is only available in the commercial edition (quoting) :
reverse engineering a database
directly from a MySQL server applies
to commercial versions of MySQL
Workbench only.
Still, you can use plain-SQL to get the create table instruction that will allow you to create a table.
For instance, the following query :
show create table url_alias;
when executed on a drupal database, would give, when using right click > copy field content on the result :
'CREATE TABLE `url_alias` (
`pid` int(10) unsigned NOT NULL auto_increment,
`src` varchar(128) NOT NULL default '''',
`dst` varchar(128) NOT NULL default '''',
`language` varchar(12) NOT NULL default '''',
PRIMARY KEY (`pid`),
UNIQUE KEY `dst_language` (`dst`,`language`),
KEY `src_language` (`src`,`language`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8'
Unfortunately (again), MySQL Workbench adds some quotes everywhere when copying this way :-(
EDIT: Using MySQL 8.0, there is an option to right click > copy field (unquoted) on the result to get the desired result without quotes.
In the end, the simplest solution, except from staying with MySQL Query Browser, will most likely be to connect to the database, using the command-line client, and execute the show create table query from there :
mysql> show create table url_alias\G
*************************** 1. row ***************************
Table: url_alias
Create Table: CREATE TABLE `url_alias` (
`pid` int(10) unsigned NOT NULL auto_increment,
`src` varchar(128) NOT NULL default '',
`dst` varchar(128) NOT NULL default '',
`language` varchar(12) NOT NULL default '',
PRIMARY KEY (`pid`),
UNIQUE KEY `dst_language` (`dst`,`language`),
KEY `src_language` (`src`,`language`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
Getting "the right portion" of the output is easier, there : no quote to remove.
And, just for the sake of completness, you could also use mysqldump to get your table's structure :
mysqldump --no-data --user=USERNAME --password=PASSWORD --host=HOST DATABASE_NAME TABLE_NAME
Using the --no-data switch, you'll only get the structure -- in the middle of some mode settings and all that.
To get an individual table's creation script just right click on the table name and click Copy to Clipboard > Create Statement.
To enable the File > Forward Engineering SQL_CREATE Script.. option and to get the creation script for your entire database :
Database > Reverse Engineer (Ctrl+R)
Go through the steps to create the EER Diagram
When viewing the EER Diagram click File > Forward Engineering SQL_CREATE Script... (Ctrl+Shift+G)
Right-click on the relevant table and choose either of:
Copy to Clipboard > Create Statement
Send to SQL Editor > Create Statement
That seems to work for me.
It is located in server administration rather than in SQL development.
From the home screen select the database server instance your database is located on from the server administration section on the far right.
From the menu on the right select Data Export.
Select the database you want to export and choose a location.
Click start export.
Simply use:
show create table <table_name>
I came here looking for the answer to the same question. But I found a much better answer myself.
In the tables list, if you right-click on the table name there is a suite of CRUD script generation options in "Send to SQL Editor". You can select multiple tables and take the same approach too.
My version of MySQL Workbench: 5.2.37
Not sure if I fully understood your problem, but if it's just about creating export scripts, you should forward engineer to SQL script - Ctrl + Shift + G or File -> Export -> first option.
1 use command
show create table test.location
right click on selected row and choose Open Value In Viewer
select tab Text
Solution for MySQL Workbench 6.3E
On left panel, right click your table and selecct "Table Inspector"
On center panel, click DDL label
In "model overview" or "diagram" just right-click on the table and you have the folowing options: "Copy Insert to clipboard" OR "Copy SQL to clipboard"
Not sure if this is still an issue, but for me in 5.2.35CE it's possible to get the create scripts by:
Database --> Reverse Engineer
Under stored connection, choose your database
Hit "Next" a few times, choose which schema you want to reverse engineer, and let the tool work
You'll get an "EER Diagram" view with all the DB's schema. If you right click on the table you care about and choose "Copy SQL to Clipboard" I think you'll have what you need.
Hopefully this helps someone else that needs it.
Open MySQL Workbench (6.3 CE)
In "Navigator" select "Management"
Then select "Data Export" (Here select the table whose create script you wish to export)
In Drop down select "Dump Structure and Data"
Select checkbox "Include Create Schema"
Click the button "Start Export"
Once export is complete it will display the location in which exported file is dumped in your system. Go to the location and open the exported file to find table creation script.
Or Check https://dev.mysql.com/doc/workbench/en/wb-admin-export-import-management.html
U can use MySQL Proxy and its scripting system to view SQL queries in realtime in the terminal.
I am trying to use the HSQLDB transfer tool to migrate a Database from MySQL. The tool is able to get the tables from the source MySQL database, however when I "start the transfer" I get the error,as follows and tables are not created in the target HSQLDB database.
org.hsqldb.util.DataAccessPointException: Unexpected token: PRIMARY in statement
[CREATE TABLE INST(INST_ID BIGINT NOT NULL ,INST_NAME VARCHAR NOT NULL ,INST_CO
DE VARCHAR NOT NULL ,PARENT BIGINT,OPEN_TIME TIMESTAMP,CLOSE_TIME TIMESTAMP,INST
_STATUS VARCHAR NOT NULL ,SCD_LICENSE CHAR(1) NOT NULL ,ADDRESS_LINE1 VARCHAR,AD
DRESS_LINE2 VARCHAR,CITY_ID BIGINT NOT NULL ,CASH_LIMIT BIGINT,DESCRIPTION VARCH
AR,INST_TYPE VARCHAR NOT NULL ,LAST_UPDATED_BY BIGINT NOT NULL ,LAST_UPDATED_DAT
E TIMESTAMP NOT NULL , CONSTRAINT PRIMARY]
Any idea how I could overcome this?
My main intention is to convert MySQL SQL into HSQLDB equivalenst, I guess there uses to be a tool to do this before MySQL workbench.
The documentation says that the Transfer Tool has not been developed for several years. I think you need to create a tool by your self, which translates a MYSQL Object DDL (Create Table, Create Procedure, etc) to a HSQL Object DDL (Which is basically SQL standards 92, 1999, 2003 and 2008).
I'm currently searching for one my self.
If you find one, please update this post?