Firebird 2.x e PHP 5.x – Mudança no tipo de campo retornardo em ibase_field_info

Em um sistema web eu desenvolvi um formatador e criador de relatórios automático em PDF. Para fazer as totalizações automaticamente, eu sempre testei se o tipo de campo de determinada coluna era INT64, utilizando $col_info['type']. Mas quando atualizamos o server com Firebird 2 e PHP 5.x esta função parou de funcionar. Fiz alguns testes e vi que nesta versão de PHP/Firebird os números com ponto flutuante retornam como NUMERIC(tamanho, precisão), e não mais como INT64. No meu caso específico, retorna como NUMERIC(18,2), que foi como criei os meus campos.
O problema disso é que se crio um campo com ponto flutuante com tamanho diferente de 18,2, terei que criar uma regra em minha classe PHP para tratar disso. Mas tudo bem, o importante é que achei a solução do problema citado.

Espero que este post seja útil.

Alteração no formato de data no PHP 5 -> Firebird 2.0

Quando migrei os dados de um servidor Debian 4 com PHP4 e Firebird 1.5 para Ubuntu 8.04 com Firebird 2 tive problemas em tratar a exibição de datas retornadas do banco. Como tenho muitos scripts que dependem do formato da data antiga (Mês/Dia/Ano) resolvi alterar diretamente no servidor o formato, ao invés de alterar os vários scripts que tinha.
A solução foi adicionar ao arquivo /etc/php5/apache2/php.ini a diretiva [interbase], e colocar o novo formato de data que eu queria. Para isso executei os seguintes comandos (como usuário root):

vim /etc/php5/apache2/php.ini

E no final deste arquivo eu inseri o seguinte conteúdo:
[interbase]
ibase.dateformat="%m/%d/%Y"

Restartei o Apache
/etc/init.d/apache2 restart

E pronto..tudo funcionou perfeitamente como era antes.

Espero que este post seja útil.

Arrumar problema de acentuação em retorno de AJAX

Para quem já se deparou com caracteres estranhos no conteúdo retornado por uma função AJAX, a solução é bastante simples.

Se você utiliza PHP como linguagem, inclua no início do arquivo que você chamou via include() a seguinte linha:
header('Content-type: text/html; charset=iso-8859-1');

No meu caso, como tenho um arquivo com a minha classe php, e algumas funções mandam outros headers, deu aquele problema de que outro header já tinha sido enviado. Para contornar este problema alterei diretamente no apache.

Editei o arquivo /etc/apache2/conf.d/charset :
vim /etc/apache2/conf.d/charset
E inseri esta linha no final do arquivo:
AddDefaultCharset ISO-8859-1

Restartei o apache e funcionou corretamente.

Espero que este pos seja útil.

Plugins do Firefox que facilitam o desenvolvimento web

Estes são os plugins do Firefox que utilizo hoje. (no Ubuntu)

Firebug

Web Developer

ColorZilla

Dica sobre o ColorZilla:
ixe os binários do site mozilla.com, e copie “por cima” dos arquivos do firefox que já vem instalado no ubuntu (isto vale tanto para a versão 1.5.* quanto para a versão 2.0 do firefox)

cd

tar zxvf [arquivo_binario_firefox].tar.gz

sudo cp ./firefox/* /usr/lib/firefox

Fonte da dica: http://revolucao.etc.br/archives/versao-definitiva-do-mozilla-firefox-20-disponivel-para-download-agora-mesmo/

Login de usuário – Armazenando nome de usuário em cookie e exibindo na tela de login

Estes dias precisei desenvolver um sistema de login igual ao do Google Apps(e vários outros), que guardam o nome do usuário em cookie, e toda vez que o usuário acessar o site para fazer o login, seu nome de usuário já aparece no campo “username”. Abaixo explico como foi desenvolvido.

Página login.php
<form method="post" action="login/acesso.php">
<label for="usuario">Usuário</label>
<input type="text" id="usuario" value="<?php print($_COOKIE['usuario']); ?>" />

<label for="senha">Senha</label>
<input type="text" id="senha" />

<input type="submit" value="Entrar" />

E na página acesso.php, você coloca toda a regra para validação do usuário. Não entrarei em detalhes aqui, pois quero focar na criação do cookie. Mas lá na sua validação, se der tudo certo com a senha do usuário, você utiliza o comando:

setcookie("usuario", $_POST['usuario'], time()+3600*24*30 , "/" );

Este último parâmetro (“/” ) é o mais importante, pois se não for informado nada, somente scripts alojados no diretório /login/ conseguirão ler este cookie. Estava criando o cookie sem esta opção, então minha página login.php não conseguia ler o cookie. Quando você informa “/” neste parâmetro, quer dizer que qualquer diretório do seu domínio pode ler este cookie.

Não me aprofundei muito nas funções de cookie, pois eu só queria mostrar como fiz esta função de salvar o username do usuário.

Espero que este post seja útil.