I've seen a lot of questions along the same-ish lines as mine, but they're just not quite exactly the same issue as me.
Here's my query:
insert into`quotes`(`QuoteID`,`QuoteRequestID`,`Number`,`UserID`,`Viewed`,
`_Latest`)
select uuid(),uuid(),
ifnull(max(`quotes`.`Number`),0)+1,'Some User ID',1,1
from`quotes`
join`quoterequests`using(`QuoteRequestID`)
where`quoterequests`.`UserID`='Some User Other ID';
And this is the error I'm getting:
Error Code: 1048. Column 'QuoteID' cannot be null
So my guess is that the select statement isn't returning anything, but how can that be since I'm using max() in my query?
Sure enough, if I remove the insert part and just run the select statement by itself, then I do get the expected results, with the new UUIDs (definitely not a null value) and all. What is happening here? Is this a bug with MySQL? My MySQL version is 5.7.14;
EDIT
So I have figured out if I wrap the select in another select, it now works as expected. Not sure if that's a solution or a workaround though, but it did get my query working.
it looks like you might have some trigger which generates the error - that is the only explanation I can think about.
Related
Can someone explain why I get an error Code 1222 (The used SELECT statements have a different number of columns) after I run this query?
INSERT IGNORE INTO table1(id1)
SELECT id2 FROM table2;
It's pretty obvious that number of columns are the same, so real issue must be somewhere else. But where? Fields are the exact same:
`id2` int(11) NOT NULL COMMENT 'blabla'
Only difference is the DB engine (MyISAM on table2, InnoDB on table1), but it can't be linked, because it works like a charm if I add more columns in my INSERT/SELECT without this one.
Any ideas? Thx.
As Tim mentioned, please provide us with table scheme and more information, because I don't see an error in the above.
For example:
INSERT IGNORE INTO test_cachetags (tag, invalidations) SELECT tag, invalidations FROM cachetags;
This query works, where TAG is varchar(255) and invalidations is integer.
OK, I finally found what was going wrong: a trigger. Basically the number of variables I had at some point did not match the number of columns. (https://dev.mysql.com/doc/refman/5.5/en/stored-program-variables.html).
It seems pretty obvious now that I found the cause, but honestly, MySQL could be more explicit. It's not like I have a single and/or simple query triggered behind the scene (this one was especially a bit complex actually).
For the record error occurred on this field, because that's the one I had forgotten to declare.
Thx for your time guys.
(NOTE: I know this is an error that's commonly asked about, but most of the time, the issue is in an INSERT statement. I couldn't find a question on this website where this error happened during an UPDATE.)
I have a table in MySQL (InnoDB / v. 5.7.19) called RESULTS which has, among others, two columns called TYPE and STATUS. Both are of type ENUM, with PASS, FAIL and IGNORE being the supported values in both. I'm trying to run this UPDATE statement on that table, using Workbench (also tried the same directly on the DB machine, using the mysql command):
update `RESULTS` set `TYPE`='IGNORE' where `STATUS`='IGNORE';
I'm getting this error:
Error Code: 1136. Column count doesn't match value count at row 1
Changing the single quotes to double quotes didn't help. I'm able to run this query successfully:
select count(`TYPE`) from `RESULTS` where `STATUS`='IGNORE';
I'm probably making a silly mistake here, but can anyone point out what's wrong with the UPDATE statement?
As requested I am posting it as an answer.
The error basically is self-explanatory like performing an operation on set of attributes but the values provided in the query are not enough. But in your case, you are performing an update operation with all attributes and their values and still, this error appears it may be a case that there is some trigger is registered for this table probably on before/after the event, If that is the case you need to update or remove that trigger if no needed.
I´m not sure if something like this has already been asked, but I didn´t find anything which helped me yet. I am storing data in a MySQL Table, one of the colums stores E-Mails. The thing is the E-Mail Adresses are shown in PHPMyAdmin but if I call
SELECT * FROM `table` WHERE `email` = 'me#example.com'
or
SELECT * FROM `table` WHERE `email`
MySQL returns an empty result, although both Querys should return minimum 1 result. email is not the PRIMARY_KEY in the table.
Does anyone have a clue what´s the Problem?
Thanks
EDIT: The query does work for the other colums of the table but not for this one
EDIT 2: The colum is labeld newsmail, has type Text with undefined Length (I also tried VARCHAR with length 255 which didn´t solve the problem), has no Null-Value and isn´t nullable, the charset is UTF-8_general_ci , no attributes, and the following fields are all blank
OK I found the problem. There was nothing wrong with the MySQL itself, but the problem was, that the email was the last element in every line of the file that I imported it from. So the email wasn´t 'mail#example.com' but instead 'mail#example.com\n' but the \n was of course not displayed by PHPMyAdmin. This explains why the query didn´t found it. And always when I put a single entry in a different colum I typed it by hand while the \n was copied when copieing the whole table with PHP.
Thanks to everyone who tried helping anyway...
Where exactly do you execute those queries? In the phpMyAdmin SQL query console or on a linux console?
If you are on a linux console and issue the mysql command be sure to add the ; at the end of each command:
# mysql
mysql> use database;
mysql> select * from table where 1;
It should return you all the entries from that specific table from the selected database
This is very strange..
I'm using PHPMyAdmin to view a table. [edit: Does the exact same thing in SQLYog.] I select one of the records in that table, and click "Delete". I then get an error saying that the column (in this case "users_id" which is an auto-increment primary key) does not exist. Yet.. when I run a select query for that same info, it returns the record fine.
So, here's the SELECT query I'm using that finds the record perfectly:
select * from users where users_id = 53
No quotes, nothing. And it returns the record with no problem. I would show you in a screen capture, but even though I have the reputation, the system isn't allowing me to post images. (ugh)
However, do this either by clicking "Delete" and "GO", or by entering SQL directly:
delete from users where users_id = 53
.. and you get an error:
Error
SQL query:
DELETE FROM `goat-dev`.`users` WHERE `users`.`users_id` =53
MySQL said: Documentation
#1054 - Unknown column 'users_id' in 'where clause'
So clearly something is off... and I just don't see what. Any suggestions?
I'm logged in as "root" with full permissions. I've quadruple-checked to be sure I have no limits on my permissions (not sure how root could).
Ok.. going to close this out. Found the problem. But left it up here for a moment to share the answer for the benefit of others.
There was a trigger that was not working properly. The trigger was actually removing data from another table if a record in this table was deleted. Apparently there was an error in that trigger. Yet.. MySQL wasn't quoting the error - rather just throwing an error on this delete. Kinda not well behaved. But.. thought this may help someone else having this problem.
Hope this is at-least a little helpful.
I'm trying to use this disgusting version of MySQL (5.1.65) where its requiring EVERYTHING to be in quotes, and is so strict about everything. I'm trying to look for duplicate entries so I'm trying to make a script that if it returns a value of what the user submitted, then obviously we have a duplicate. Well thats working on MY server, not this one.
This is what I'm trying to execute. This goes through fine without error,
SELECT * FROM `keylist` WHERE 'key' = '7489asdf32749asdf8237492asdf49837249'
The issue is that 7489asdf32749asdf8237492asdf49837249 IS in the database as a varchar...Its exactly the same. But the weird thing is that if I do
SELECT * FROM `keylist` WHERE key = '7489asdf32749asdf8237492asdf49837249'
That does not work while if I did that for selecting my ID it works.
I have no idea what I'm doing wrong, but this stupid MySQL version sure isn't helping.
Overall, my issue is that I'm trying to look for a duplicate, so I do a WHERE key = statement, and a key that IS in there, returns nothing when I KNOW its in there.
key is a reserved word in MySQL - http://dev.mysql.com/doc/mysqld-version-reference/en/mysqld-version-reference-reservedwords-5-0.html
Your first version works becomes the backtics - ` ` force interpretation to the actual column name.