What's wrong with my syntax here? I'm adhering strictly to the rules in the Sybase Reference
CREATE TABLE dashlogactions (
action_id SMALLINT NOT NULL DEFAULT IDENTITY PRIMARY KEY,
action_name VARCHAR(64) NOT NULL UNIQUE
)
SQuirrel SQL Client (version 3.3.0) is reporting an error:
Error: Incorrect syntax near the keyword 'DEFAULT'.
SQLState: ZZZZZ
ErrorCode: 156
Also SQuirrel is showing the words IDENTITY and KEY in red and when I hover over them, it says Invalid ColumnDefault for IDENTITY and EOF expected for KEY.
I get the same results if I replace the word IDENTITY with AUTOINCREMENT.
I'm using Sybase Adaptive Server Enterprise, although I'm not sure of the version.
You need to supply a default value if you use default. See the docs.
Related
could you please help me? I bought a domain just for learning databases etc. and I created my model of a database in MySQL Workbench. I generated a script and tried importing it into my database using phpMyAdmin. This is the script:
CREATE TABLE IF NOT EXISTS `knight` (
`idKnight` INT NOT NULL AUTO_INCREMENT,
`strength` INT NOT NULL DEFAULT 1,
`agility` INT NOT NULL DEFAULT 1,
`vitality` INT NOT NULL DEFAULT 1,
`attack` INT GENERATED ALWAYS AS (agility*strength) STORED,
`defense` INT GENERATED ALWAYS AS (vitality*strength) STORED,
`idUser` INT NOT NULL,
`idTavern` INT NULL,
PRIMARY KEY (`idKnight`),
INDEX `fk_user_idx` (`idUser` ASC),
INDEX `fk_tavern_idx` (`idTavern` ASC),
CONSTRAINT `fk_user` FOREIGN KEY (`idUser`)
REFERENCES `user` (`idUser`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_tavern` FOREIGN KEY (`idTavern`)
REFERENCES `tavern` (`idTavern`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB
And this is the error:
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'GENERATED ALWAYS AS (agility*strength) STORED,
defense INT GENERATED ALWAYS ' at line 6
Now the question is how do I synchronize the MySQL Workbench version of a database for which the script is generated, and the database itself. The database is Inno DB.
Thanks for your help
EDIT: MySQL version of my server is: 5.6.28
This type of problem shows the importance of using the same version of database in development as you will eventually use when you deploy to your production server. So you don't get surprised by incompatibilities.
You can run that script against your MySQL 5.6 server only if you avoid SQL features introduced in more recent versions of MySQL. This includes generated columns, which were first introduced in MySQL 5.7.
So you need to remove these columns, or else change them to plain INT columns, without the generated option.
`attack` INT GENERATED ALWAYS AS (agility*strength) STORED,
`defense` INT GENERATED ALWAYS AS (vitality*strength) STORED,
If you need those columns in query result sets, you have a few alternative solutions:
Add them as expressions in the select-list of a SELECT query:
SELECT (agility*strength) AS `attack`, (vitality*strength) AS `defense`
FROM `knight` ...
Or you could create a VIEW to encode a query with those expressions.
Or you could add those columns as plain integers, and write TRIGGERs on INSERT and UPDATE to keep them in sync with the other columns.
MySQL 5.6.28 was released in December 2015, and the whole 5.6 branch is past its end-of-support date. That means if any security bugs are discovered from now on, they won't be fixed. Besides, you're already using an outdated release of 5.6, with many bugs. The last 5.6 release was 5.6.51 in January 2021.
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'm working on a model in MySql Workbench 8.0, when I click on forward engineering and try to generate the script of my model I get
Executing SQL script in server
ERROR: Error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'VISIBLE,
CONSTRAINT `fk_Compras_Personas`
FOREIGN KEY (`persona_id`)
R' at line 9
SQL Code:
-- -----------------------------------------------------
-- Table `bd_inventario2018_2`.`compras`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `bd_inventario2018_2`.`compras` (
`nmcompra` INT(11) NOT NULL,
`persona_id` INT(11) NOT NULL,
`fecompra` DATE NOT NULL,
PRIMARY KEY (`nmcompra`, `persona_id`),
INDEX `fk_Compras_Personas_idx` (`persona_id` ASC) VISIBLE,
CONSTRAINT `fk_Compras_Personas`
FOREIGN KEY (`persona_id`)
REFERENCES `bd_inventario2018_2`.`personas` (`id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8
SQL script execution finished: statements: 6 succeeded, 1 failed
Fetching back view definitions in final form.
Nothing to fetch
Or when i try to syncronize the model I get
Executing SQL script in server
ERROR: Error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'VISIBLE' at line 4
SQL Code:
ALTER TABLE `bd_inventario2018_2`.`productos`
ADD COLUMN `anchetas_id` INT(11) NOT NULL AFTER `psventa`,
ADD COLUMN `productoscol` VARCHAR(45) NOT NULL AFTER `anchetas_id`,
ADD INDEX `fk_productos_Anchetas1_idx` (`anchetas_id` ASC) VISIBLE
SQL script execution finished: statements: 3 succeeded, 1 failed
Fetching back view definitions in final form.
Nothing to fetch
Someone knows what's happening? This is an automatic process, I'm not overwritting anything,
Thanks
MySQL Workbench is generating the script for MySQL 8 (which supports the new invisible indexes), which you likely do not have.
You need to specify the MySQL version you are using, either in Model\Model Options\MySQL\Target MySQL Version or, globally, in Edit\Preferences\Modelling\MySQL\Target MySQL Version.
Alternatively, you can go on the MySQL Workbench GUI, Edit->Preferences then Modeling->Mysql and change the default target MySQL.
I had the same problem, using version = 8.0.17.
The error originates when a relationship is formed if No action is selected in the "Foreign Key Options" section. Ensure that the Skip in SQL generation is checked (When No action is selected).
This should solve the problem!
I have this line in an SQL table:
Income NUMBER(12,2),
And I want to recreate the table in mysql, but it's throwing me this error:
error 1064 (42000): You have an error in your SQL syntax; check the manual to use near '2))' at line 4
This is how I'm creating the table:
CREATE TABLE Doctors(
DoctorId INTEGER(5) PRIMARY KEY,
DoctorName VARCHAR(20),
Income INTEGER(12,2));
How can I do this in mysql?
*I have been able to replicate the table in sqlite without errors.
If you are trying to do what your question title states (i.e. store two integer values into the same column), you may be looking to use an array. Databases like PostgreSQL support arrays (see PostgreSQL array documentation), but MySQL doesn't do so natively (see MySQL Documentation). However, the MySQL documentation suggests using a language extension to serialise/deserialise the data (see PHP example).
Otherwise, it may be that you are simply looking for a DECIMAL type:
Income DECIMAL(12,2)
See MySQL Documentation for fixed-point types
I have a database with a table named order.
When i run php symfony doctrine:build --all, i got the folowing error:
SQLSTATE[42000]: Syntax error or
access violation: 1064 You have an
error in your SQL syntax; check the
manual that corresponds to your MySQL
server version for the right syntax to
use near 'order (id BIGINT
AUTO_INCREMENT, status VARCHAR(255),
colissimonumber VARCHAR(25' at line 1.
Failing Query: "CREATE TABLE order (id
BIGINT AUTO_INCREMENT, status
VARCHAR(255), colissimonumber
VARCHAR(255) NOT NULL, created_at
DATETIME NOT NULL, updated_at DATETIME
NOT NULL, PRIMARY KEY(id)) ENGINE =
MyISAM".
The problem is clearly that order has no backquotes arount it (if i run manually the query in phpmyadmin with backquotes, it works)
How do i tell doctrine to add backquotes around table and field names? Any workaround exept renaming my table ?
I run symfony 1.4.9 with doctrine 1.2
You can turn on Doctrine_Core::ATTR_QUOTE_IDENTIFIER in your doctrine configuration mthod on projectConfiguration which will quote tables and col names but its not recommended:
Just because you CAN use delimited
identifiers, it doesn't mean you
SHOULD use them. In general, they end
up causing way more problems than they
solve. Anyway, it may be necessary
when you have a reserved word as a
field name (in this case, we suggest
you to change it, if you can).
http://www.doctrine-project.org/projects/orm/1.2/docs/manual/configuration/en#identifier-quoting
You probably want your model to be named Order, but this doesn't mean that the corresponding RDBMS table must be named the same.
Order:
tableName: project_order
columns: ...
Got similar error when upgrading from MySQL 5.7 to MySQL 8.0. RANK() is a function added in MySQL 8.0 whereas one of the table in our database has rank as column name.
My Setup:
- Symfony 1.5
- Doctrine 1.2
- PHP 7.4.24
- MySQL 8.0.27
- Ubuntu 20.04.1
Here are three possible solutions.
Solution 1: Add quote_identifier: true in config/databases.yml file. Also, clear cache after change in configuration with php symfony cc or php symfony cache:clear.
all:
doctrine:
param:
attributes:
quote_identifier: true
Solution 2: Turn on Doctrine_Core::ATTR_QUOTE_IDENTIFIER in config/ProjectConfiguration.class.php file on configureDoctrine() method.
$conn = Doctrine_Manager::getInstance()->getCurrentConnection();
$conn->setAttribute(Doctrine_Core::ATTR_QUOTE_IDENTIFIER, true);
Solution 3: Turn on Doctrine_Core::ATTR_QUOTE_IDENTIFIER on specific table(s) which are potentially breaking the system.
$table = Doctrine_Core::getTable('table_name');
$table->setAttribute(Doctrine_Core::ATTR_QUOTE_IDENTIFIER, true);
Note: From Doctrine 1 docs
Just because you CAN use delimited identifiers, it doesn't mean you
SHOULD use them. In general, they end up causing way more problems
than they solve. Anyway, it may be necessary when you have a reserved
word as a field name (in this case, we suggest you to change it, if
you can).