It looks like the term COLUMN is unnecessary in "ALTER TABLE <table_name> ADD COLUMN ..." for Oracle migration scripts and causes error when executed on a database.

I am having difficutly uploading sql exported from vertabelo to mysql database hosted on microsoft azure cloude. I was told this has something to do with the Transact SQL format the microsoft uses. IS there a way to export the SQL in a format that is compatible with mysql on microsoft azure? Or converting to be acceptable for mysql using transact sql?

I already tried exporting in every form (sql lite, mysql 5.x etc.)

I was not able ot use my work email address example@example.center to sign up

How is it possible that I cannot share the model from model details screen?

Then I try to find it in Dashboard - to no avail.

Eventually, it is found in Documents section. This is not convenient to the user.

It will be great if you add an app

Add the ability to integrate models from vertabelo in confluence pages.

We are looking into data modeling tools, and vertabelo looks like a great candidate.

We use confluence in the company for intranet and knowlede sharing, and therefore we will need to integrate the published models in confluence. I cannot see how this can be done.

We are not referring to a link, but rather to be able to create a view only for the model, like it is done in some of your blog posts.

[MySQL 5.7]

I found that the queries

CREATE TABLE `test` (
  `test_id` int(16) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

ALTER TABLE `test`
  ADD PRIMARY KEY (`test_id`);

ALTER TABLE `test`
  MODIFY `test_id` int(16) AUTO_INCREMENT;

seem to be parsed in a strange way. After importing the above as a script and viewing the generated table as SQL it shows

CREATE TABLE test (
  test_id int(16) NULL AUTO_INCREMENT,
  test_id int(16) NULL AUTO_INCREMENT,
  CONSTRAINT test_pk PRIMARY KEY (test_id)
) ENGINE InnoDB CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

Which is not what I had in mind but I cannot figure out the problem. 

MySQL Workbench parses this in the wrong way, too - ignoring the MODIFY completely.

PHPMyAdmin on the other hand does it correctly.

Any thoughts on this? :-)

Thanks!

Add an option to generate a Liquibase file for updates. Next to the Generate migration SQL. So the versions (exclude auto saved) contains Liquibase changesets.