6
Trying to answer this issue (as the AP even presented, without resorting to normalization) I tried to use the group_concat
it returns me the object of type BLOB
.
Table:
CREATE TABLE `teste` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`nome` varchar(45) DEFAULT NULL,
PRIMARY KEY (`id`)
);
Data in the Table:
Consultation:
SELECT group_concat(t.id) FROM teste t;
Upshot:
Is there a problem in Mysql Query Browser? In query?
Note:
In the matter at hand, I saw examples that worked right over here nothing else.
In the Workbench
worked well, the same query.
Very strange... Could [Dit] your question including your tables, data and queries?
– gmsantos
Sorry there @gmsantos, missed the query, the data are already there right?
– Cold
A
create table
would be more useful than the image, if you do not mind editing.– gmsantos
In the good @gmsantos...
– Cold
It’s there @gmsantos, I put the script to create the table.
– Cold
Seems to be a bug in an old version of Workbench that, could post what returns the query :
show variables like "%concat%";
?– gmsantos
Um... the result is 1024.
– Cold
Let’s go continue this discussão in chat.
– gmsantos
I think it’s logical. I think you make a mistake between the guy inside the BDD and the guy in the results. For example, if you have a table with varchar(150) on one side and varchar(300) on the other side, you will not be able to have a result that will agree with the 2 types because you can have a result of 450 car. If now you have a varchar(300) and you want.
– Peter
It seems that it is a Bug @Peter. As for the explanation of the logic in this I have not quite understood. I will reread your comment.
– Cold
What I mean is that the result has no "type". What has "type" is only the data inside the BDD.
– Peter
So it’s not a bug, this is correct @Peter?
– Cold
Correct. As in Antony’s answer, the result cannot be of the same type as the data because in many cases, the size of the result ultrapasa the size of the data type.
– Peter