I am completely new to both SQL and MySQL, and I've created a Schema and want to make a table. I've specified all my fields, but I find that every time it generates code, it is incorrect. This happened when I previously tried to make my schema, but I was able to fix it. However, this time around I'm completely lost.
Here's my visual layout, the generated code, then the error log:
Related
I'm trying to execute a .sql script which inserts values into a database.
Problem is, there's some issues in the syntax of the script.
Error Code: 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 '' at line 1 0.078 sec
But the script is pretty large, a few Mos, so I can't check manually where the error is. According to the error message it should be close to quotes, but sadly all the values inserted are on one line in the script file so the indication "on line 1" is not helpful at all.
Is there a way to get a precise position for the error ? I'd like, in particular, the column number where the syntax is wrong. Is that possible ?
I'm using command of the type :
mysql -u root -p Wikicategory < path\to\script\script.sql
MySQL Workbench uses a different parser (ANTLR4 based) than the MySQL server (yacc based). ANTLR4 based parsers often (but not always) can report errors with a precise location.
I don't think the query is too large. If it were you would get a different error (because the connection buffer would not be large enough).
So, you best option is to reformat the query. For SELECTs you can use MySQL Workbench, but better try Visual Studio Code with the SQLTools plugin. Not the best results there either, but it seems to be able to reformat all types of queries.
Then run the script again to see if you get a better error location.
I have mysql2, inquirer, and console.table installed. I seems to be getting multiple errors when trying to create a table within my schema file.I have tried to reinstall all my packages to no avail. I have yet to create the seeds file as I thought i could knock the schema out of the way first if that might be whats causing the problem. Multiple errors in Schema file
I'm a bit stumped by this. I've used mysql 5.7x before and I've always been able to fix this issue by removing ONLY_GROUP_BY from the sql_modes in the mysql config. However, today I appear to be unable to do so, even removing it from the sql_modes setting doesn't stop me from recieving this error.
I know what causes the error and I know there is a work around that you can add to the SQL, however I do not have time to fix the litteral hundreds of queries in our application which cause this.
SQLMode setting in mysql.cnf:
sql_mode = " ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
This is then confirmed by running the query:
SELECT ##SQL_MODE;
Result:
'ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'
However, when running the stored proc, it still produces the error:
SQLSTATE[42000]: Syntax error or access violation: 1140 In aggregated query without GROUP BY, expression #1 of SELECT list contains nonaggregated column 'schema.emp.company_id'; this is incompatible with sql_mode=only_full_group_by
Does anyone know why mySQL appears not to recognise that the option has been disabled?
I'm running 5.7.21-0ubuntu0.17.10.1 (on Ubuntu 17.10, not surprisingly!)
Well, just to double the bizarre-ness of the entire issue, it appears that if you drop and recreate the stored proc (with no code changes, its exactly the same), the issue goes away.
This schema wasn't an existing one and mySQL upgraded over it, I did a fresh install of Ubuntu 17.10 on my machine only a few weeks ago and restored everything from backups onto it.
I'm at a loss to explain the above, I can only presume mySQL caches sql modes when it compiles(?) stored procs. I don't know if it does compile then when you create them, but it's clearly caching something.
I am using the migration wizard provided by MySQL workbench 6.3 to convert a SQL Server database into a MySQL. I tested the connection between both DBs and they are valid for the migration wizard. Once The migration wizard has completed I am left with 22 migration warnings and they are all the same warning:
Truncated key column length for column 0 to 16
I am having a hard time finding any similarities between the tables that are receiving warnings to narrow down the issue. There are tables with the same types of data that are not receiving these errors.
Here is an example of one of the tables affected by this warning.
Does anyone know what is/what could be causing these migration warnings?
if you need more information/images please let me know.
Migration wizard show this warning when find index that have different length on source and target databases. In fact you should also get index name in that message - ... for column <name> from ..., but it's empty. I guess something goes wrong, but to investigate that I need to reproduce issue on my machine. Please fill bug report on bugs.mysql.com and attach there sample database (you can make it private if you wish). Then paste link here.
Warning doesn't matter. Just remember to rename the schema while migrating I have attached an image for better understanding
https://i.stack.imgur.com/v6PGK.png
I was importing one table in a MySQL Server when the power went down. After this event I tried to query the table I was importing, but got the error 2013, only when I'm querying this table (the others work just fine).
I have physical access to the server, tried to execute any query from there (tried to SELECT, and even DROP TABLE) but still got the same error.
Does anybody know a solution where I can re-build only the table (without building the whole schema from scratch?)
I'm adding this as an answer rather than having lots of comments underneath. I must state in advance that I've not used MySQL but I have used SQL server a lot so I'm hoping that something I say may help.
You say the table is still there. Was it created as part of the operation you were doing or had it been there for a while?
What happens if someone else or a different account tries to access this table?
Is there anything on this page that is relevant to your problem?
http://dev.mysql.com/doc/refman/5.0/en/gone-away.html