MySQL limita uso após atualização para Ubuntu 16.04

[maurov]

Boa tarde, pessoal.

Tenho um sistema que roda em MySQL e funcionava normalmente. Ao atualizar o servidor para Ubuntu 16.04, algumas perguntas foram feitas pelo processo automático da atualização e por não saber o resultado prático de cada pergunta, quando parecia aconselhável, optava por atualizar o arquivo que era pedido.

Verifico agora que algumas operações foram bloqueadas no uso.
A principal delas, no momento é: Ao criar um novo registro, o campo "id" que está configurado como AI (auto-increment) não consegue realizar a ação. Já desmarquei e marquei de novo, salvando. Parece algo de permissão.

Nao foi possivel fazer a query insert into.
Incorrect integer value: '' for column 'id' at row 1

Alguém conhece MySQL para ajudar?

[zekkerj]

Quando o sistema pergunta se pode atualizar alguma coisa, é pq ele encontrou algum arquivo que está diferente do original, o que, via de regra, significa que você o alterou. Normalmente o processo de atualização deixa uma cópia do arquivo original no lugar; veja nos diretórios de configuração do mysql se vc encontra essas cópias, e consegue ver o que mudou de um pro outro.

[maurov]

Não saberia onde procurar estes arquivos sobrepostos.

Mas segue o que consegui identificar.
- Consigo me logar no sistema. Aceita meu usuário e minha senha.
- Consigo abrir páginas, (As páginas iniciam um include_conexao.php)
- Consigo efetuar consultas.
- Não consigo inserir registros. Incorrect integer value: '' for column 'id' at row 1 (é autoincrement)
- Não consigo atualizar alguns registros. Incorrect integer value: '' for column 'pjur' at row 1
- Consigo atualizar outros registros.

Em suma, não identifico o problema exato, muito menos onde corrigir.

[zekkerj]

Não saberia onde procurar estes arquivos sobrepostos.

Não são arquivos sobrepostos, são backups do arquivo antes da atualização. Ficam no mesmo local onde ficariam os arquivos originais, e sendo arquivos que você pode ter modificado, a princípio ficariam em "/etc/mysql".

[maurov]

A pasta /etc/mysql tem dois arquivos com nome parecido, my.conf e mycnf.fallback.

Em my.conf

Código Selecionar Expandir

!include /etc/mysql/conf.d
!include /etc/mysql/mysql.conf.d

Em my.cnf.fallback

Código Selecionar Expandir

!include /etc/mysql/conf.d

Não há outros arquivos com terminações do tipo .bkp ou .old.

[zekkerj]

vc consegue abrir essa base com o phpMyAdmin?

[maurov]

Sim, consigo.
Foi a primeira coisa que fiz. Só movimento o SQL pelo phpmyadmin. Nunca usei command line para nada nele, só para testar acesso com o mysql -u root -p.
No phpmyadmin, desmarquei a opção auot-increment do campo 'id' e depois ativei de novo, para ver se funcionava. Neste campo achei uma opção que não me recordo de ter visto antes, um checkbox chamado Adjust Privileges, que vou copiar abaixo. Mas não sei se o problema se refere a isso.

6.39 What is the "Adjust privileges" option when renaming, copying, or moving a database, table, column, or procedure?

When renaming/copying/moving a database/table/column/procedure, MySQL does not adjust the original privileges relating to these objects on its own. By selecting this option, phpMyAdmin will adjust the privilege table so that users have the same privileges on the new items.

For example: A user 'bob'@'localhost' has a 'SELECT' privilege on a column named 'id'. Now, if this column is renamed to 'id_new', MySQL, on its own, would not adjust the column privileges to the new column name. phpMyAdmin can make this adjustment for you automatically.

Notes:

    While adjusting privileges for a database, the privileges of all database-related elements (tables, columns and procedures) are also adjusted to the database's new name.
    Similarly, while adjusting privileges for a table, the privileges of all the columns inside the new table are also adjusted.
    While adjusting privileges, the user performing the operation must have the following privileges:
        SELECT, INSERT, UPDATE, DELETE privileges on following tables: mysql.`db`, mysql.`columns_priv`, mysql.`tables_priv`, mysql.`procs_priv`
        FLUSH privilege (GLOBAL)

Thus, if you want to replicate the database/table/column/procedure as it is while renaming/copying/moving these objects, make sure you have checked this option.

[zekkerj]

Não parece que o problema seja de privilégio, mas sim de manutenção da integridade da base.

[maurov]

É uma hipótese, mas não considero provável.
A base ficou intocada, não houve restauração nem reinstalação. Foi uma atualização do OS da máquina da versão 14 para a 16, sempre LTS.
E lembro que houveram perguntas no processos automático do upgrade, mas eu não sabia exatamente no que cada coisa iria acarretar. Agora precso descobrir o que tem que ser reajustado.

[maurov]

Para ir atualizando:
A versão do MySQL foi atualizada para 5.7.16 quando da atualização do Ubuntu.

Criei registros direto pelo phpmyadmin, obviamente logando como root, e percebi que:

1) Fez a query INSERT INTO ('id', 'nome') VALUES ('NULL', 'joao'). A query que operava no script php consta como INSERT INTO ('id', 'nome') VALUES ('','$nome'), sendo $nome='joao' no form.
O campo id é autoincrement.

2) Os campos que ficavam em branco no form (não sei se são trazidos como zero para o DB), precisaram ter valores digitados no phpmyadmin, mesmo que fossem zero.

3) Os campos de data não aceitaram ser digitados no phpmyadmin como 0000-00-00. Pediu data válida. No form, os campos ainda não usados, como datadequitacao normalmente estão em branco.

Que nó.

[zekkerj]

Se o campo é autoincrement, pq vc está atribuindo valores a ele? Eu faria só "INSERT INTO ('nome') VALUES ('joao')", sem passar um valor pra "id".

[maurov]

Aprendi daquele jeito e funcionava.
Mas achei também essa sugestão de fazer sem especificar o id num forum de mysql na web.
Vou testar e atualizo aqui os resultados.

Acho que temos um norte.

[maurov]

O que mudou quando da atualização para a versão 5.7 foi que o DB não aceita mais campos vazios. Então:
- Ao gerar um novo registro, não aceita mais a condição de ter INSERT INTO ('id', 'nome') VALUES ('','$nome'), sendo $nome='joao' no form e com o campo id é autoincrement no MySQL.
- Ao gerar um novo registro, caso o form mantenha algum dado vazio, tipo uma checkbox qualquer, a qual é Integer ou TinyInteger, tem que marcar a opção NULL no MySQL.
- Ao alterar um determinado campo pré-existente que possua uma condição citada no ítem anterior,  NULL tem que estar marcado no DB.

Valeu  mais esta parceria.

[zekkerj]

Pra mim, um campo autoincrement que aceita valores NULL é uma incongruência, não? Vc define o campo como autoincrement justamente para que ele assuma um valor a partir do último registro inserido, como (ou por qual motivo) você vai aceitar que ele vire nulo?

[maurov]

Concordo. O campo id, que tem autoincrement, não é NULL. Mas num form, nem todos os campos são preenchidos. Estes últimos que devem poder aceitar a opção NULL.