Pergunta

De alguma forma GROUP_CONCAT é capaz de arrebanhar seis "páginas" de um artigo (cada um armazenado como texto) e atirá-los em um único MEDIUMTEXT sem perder quaisquer dados, mas há alguns de uma página artigos que são mais longos do que o normal (mas ainda, obviamente, se encaixam no tipo de dados TEXT) que perder uma quantidade significativa de dados. Alguém sabe o que está acontecendo?

consulta original:

SET group_concat_max_len = 16000000;
UPDATE Threads t SET t.Content = (SELECT GROUP_CONCAT(a.Content ORDER
BY a.PageID SEPARATOR '<!-- pagebreak -->') FROM MSarticlepages a
WHERE a.ArticleID = t.MSthreadID GROUP BY a.ArticleID);

Mais uma vez obrigado por tomar o tempo para orientar a minha auto ignorante!

Foi útil?

Solução

O manual de referência para MySQL 5.0 ( http://dev.mysql.com/doc/refman/5.0/en/group-by-functions.html#function_group-concat ) afirma:

A partir do MySQL 5.0.19, o tipo retornado por GROUP_CONCAT () é sempre VARCHAR menos group_concat_max_len é maior do que 512, caso em que, ele retorna um BLOB. (Anteriormente, retornou um BLOB com group_concat_max_len maior que 512 somente se a consulta incluiu uma ORDER BY cláusula.)

Com base nestes dados, o tipo de retorno seria BLOB, não MEDIUMTEXT. Wwould que seja possível que a concatenação é, no total, mais de 2 ^ 16 (65536 bytes), que é o limite para blob?

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top