MDB2 desliga e esquece-se de conjunto de caracteres de configuração quando reconectando

Question

Recentemente, depurado um bug estranho.Uma solução foi encontrada, mas a solução não é inteiramente satisfatória.

Nós usamos IntSmarty para localizar o nosso site, e armazenar as seqüências localizadas em um banco de dados usando o nosso próprio invólucro.Em seu processo de destruição, IntSmarty salva as novas seqüências de caracteres que ele pode ter, resultando em uma chamada de banco de dados.

Nós usamos uma instância Singleton de MDB2 para fazer consultas MySQL, e depois de ligar usamos o SetCharset()-função de alterar o conjunto de caracteres UTF-8.Descobrimos que as cadeias de caracteres que foram salvos por IntSmarty foram interpretados como ISO-8859-1 quando o final inserções foram feitas.Nós olhou atentamente para o registo de consulta, e descobriram que a conexão com o MySQL for desconectado antes IntSmarty do processo de destruição foi chamada.Em seguida, ele ficou restabelecido, mas não "CONJUNTO de NOMES utf8" consulta foi emitida na nova conexão.Isto resultou que os salvos cadeias tenho interpretado como ISO-8859-1 pelo MySQL.

Parece não haver opções que definir o conjunto de caracteres padrão no MDB2.A nossa solução para este problema foi mudar o servidor MySQL configuração, adicionando

init-connect='SET NAMES utf8'

para a minha.cnf.Isso só resolve o problema que o nosso conjunto de caracteres é sempre o mesmo.

Assim, existe alguma maneira que eu possa impedir a ligação de ser demolido antes de todas as consultas foram executadas?Posso forçar o MDB2 instância a ser destruídos depois de tudo o resto?

Ligar conexões persistentes funciona, mas não é a resposta desejada.

Answer 1

A partir do PHP5 documentação:

O processo de destruição método será chamado assim que todas as referências a um objeto em particular forem removidas ou quando o objeto for explicitamente destruído ou em qualquer ordem na seqüência de desligamento.

Documentação do PHP

(ênfase minha)

O que provavelmente está acontecendo é que o script não explicitamente destruir o objeto, e então, quando o PHP fica para o fim do script ele começa a limpar as coisas em qualquer ordem parece--, que, no seu caso, é fechar a ligação de base de dados primeiro.

Se você explicitamente destruir o IntSmarty objeto antes do final do script, que deve resolver o seu problema.