Firebird SQL: por que tão impopular? (e como melhorar a situação)

Firebird SQL: por que tão impopular? (e como melhorar a situação) 1 Recentemente iniciei um novo projeto no qual  precisei responder a questão: qual SGBD usar? Até então, vinha usando o MySQL para basicamente tudo (fou fanático pelo MySQL), porém, devido ao seu esquema de licenciamento e algumas restrições do próprio projeto, tive de ignorá-lo desta vez.

Foi quando me lembrei de um velho conhecido: o Firebird! Devo confessar: depois do MySQL, o Firebird se encontra em segundo lugar (talvez empate com o PostgreSQL) para mim.

Porém algo no Firebird sempre me incomodou: basicamente ele só é popular entre programadores Delphi. Mais interessante ainda: provávelmente o Firebird é mais popular aqui no Brasil que no resto do mundo (temos uma comunidade excelente por sinal: http://www.firebase.com.br/fb/).  Isto é natural, visto ser derivado do Interbase da Borland, cujo Delphi dominou o mercado de desenvolvimento no Brasil por vários anos. Porém, ao observar as vantagens do Firebird, o mistério referente à sua baixa popularidade fora deste grupo só aumenta:

  • Licença realmente livre: ao contrário do MySQL que te prende no GPL se você o quiser utilizar gratuitamente, o Firebird é de fato 100% livre para uso em aplicações comerciais.
  • O básico dos SGBDs “grandes”: stored procedures, triggers, conformidade com A.C.I.D., backups online, generators, integridade referencial,  suporte a diversos tipos de caracteres… todas as buzzwords estão presentes no Firebird.
  • Footprint mínimo: o Firebird possui uma versão embutida (uma única DLL) que ocupa menos de 1 Mb e não corta básicamente NENHUM recurso da versão completa!
  • Baixos requisitos de hardware: o bichinho pode ser executado em práticamente qualquer computador!
  • Multi plataforma: Linux, Windows, Mac OS, Solaris e outras
  • Suporte a
  • Performance razoável: não é lá estas maravilhas, mas fica entre o PostgreSQL e o MySQL
  • O projeto é ativo (e muito): apesar de sua baixa popularidade, o projeto é bem ativo. Em abril deste ano, por exemplo, saiu o beta da versão 2.5 do projeto.
  • Banco de dados fácil de transportar: este ponto é polêmico, mas o fato do banco de dados estar contido em um único arquivo torna suas bases de dados muito fáceis de serem transportadas (é possível ter um banco de dados com mais de um arquivo).
  • BDs com tamanho ilimitado: a limitação do tamanho do BD é definida pelo sistema de arquivos utilizado pelo sistema operacional. Se o seu arquivo superar este limite, basta dividir o seu banco de dados em mais de um arquivo.
    (o maior banco de dados conhecido possui 960 Gb de tamanho link)
  • 100% compatível com o padrão SQL 92
  • Inúmeras formas de ser acessado: basicamente é possível acessar o Firebird a partir de qualquer linguagem de programação. Existem diversos drivers ODBC, JDBC, ADO, PHP, .net, etc.

Tenho utilizado o Flamerobin para administrar o banco de dados do projeto e está sendo uma experiência muito agradável. Mas é muito triste constatar que desde que escrevi o meu conversor de banco de dados no formato Microsoft Access para Firebird em 2006 (MDB2FDB http://www.firebase.com.br/fb/downloads.php?categ=8) a situação não mudou em nada: Firebird continua sendo popular apenas por desenvolvedores Delphi.

Dado que gosto do produto, e acho um absurdo o seu problema de popularidade, penso que seria interessante listar algumas formas de ajudar o projeto. Segue minha lista de sugestões:

  • Usar o Firebird. Sério: experimente o bichinho. Caso não o conheça, você ficará surpreso com o fato de uma imensidão de recursos caberem em um software tão pequeno.
  • Caso já use o Firebird, você pode também fazer doações ao projeto.
    Eis o link: http://www.firebirdsql.org/index.php?op=ffoundation&id=contributions
  • É também possível ser um patrocinador do mesmo.
    Eis o link: http://www.firebirdsql.org/index.php?op=ffoundation&id=sponsor_howto
  • Caso sinta falta de alguma ferramenta para trabalhar com o Firebird, você pode criar a sua e distribuir gratuitamente, como eu fiz com o MDB2FDB.
    Se não for para distribuir gratuitamente, o simples fato de produzir algo para o Firebird já ajuda a aumentar a sua popularidade.
  • Escrever a respeito, e participar de grupos de usuários.

Claro, eu não poderia deixar de imaginar quais as razões pelas quais o projeto não é tão popular quanto o MySQL ou PostgreSQL:

  • Não há uma empresa de peso como Sun/Oracle ou IBM apoiando o projeto. Ele é mantido basicamente por voluntários e alguns patrocinadores.
  • O site oficial (http://www.firebirdsql.org). Parece futilidade, porém a primeira impressão que o projeto passa é péssima!
    O maior patrocinador do projeto é a IBPhoenix: uma empresa cujo negócio é o Firebird. Porém, mesmo esta ainda possui um site com péssima aparência.
  • O fato de ter sido desde o início associado ao Delphi. Com a decadência da ferraemnta, a popularidade do banco também foi junto.
  • Documentação pobre: ao acessar a documentação pelo site, você encontra diversos links voltados para as versões anteriores à 2.0 do Firebird. Além de que, é bem desorganizada.

Porém, estas razões são apenas um chute. Gostaria de saber agora de vocês as suas opiniões a respeito deste SGBD.

114 comments on “Firebird SQL: por que tão impopular? (e como melhorar a situação)

  1. Alex

    Eu trabalho desde 2002 com Firebird e nunca tive problemas com base de dados corrompida. Com certeza é o hardware que está causando esses problemas. Dos SGDBs gratuítos, o Firebird é o melhor.

    Responda

  2. João

    Trabalhamos com firebird em mais de 130 bases espalhadas pela nossa região, e em 11 anos tivemos problemas em apenas 3 empresas, por problemas de hardware.
    E penso que, o fato de haverem bancos melhores, não significa que o firebird seja ruim. Na verdade é um banco super fácil de instalar, configurar, e manter. Além de ser super indicado para micro, pequenas e empresas de médio porte.

    Responda

    admin Reply:

    Oi João, compartilho da mesma opinião que a sua.

    Responda

  3. Edilmar Alves

    Eu trabalho com FB desde a época da dupla InterBase + Delphi da Borland em 1994, e já passei por todas as versões do FB. Atualmente uso FB também com Java e funciona muito bem. Uso apenas FB 2.5 e está muito bom, resolveu muitos problemas antigos que o FB tinha. Bases corrompidas no FB normalmente são culpa de hardware e não do software em si. Já tive problemas que consegui resolver com gfix/gbak, mas é fundamental ter uma politica 100% de backup dos dados, pois BDs de qualquer fornecedor estao sujeitos a serem corrompidos. Espero que o FB 3.0 resolva o problema definitivamente do dilema Classic x SuperServer.

    Responda

    tiago pereira Reply:

    agora sao 3: classic, superclassic e superserver. padrao selecionado é superserver

    Responda

  4. j2c9m7

    Firebird eh muito bom, ja tive banco com 10 milhoes de registros, e consultas super rapidas, tudo depende dos indices e de como sao formuladas as querys; 45 segundos e lento, e 100 mil registros numa consulta eh inviavel, acho que tem alguma coisa errada no seu sistema!

    Responda

    admin Reply:

    Fato. Já vi monstros rodando no Firebird também sem problemas.

    Responda

  5. junior

    alkem sabe me dizer se tem como recuperar base de dados imformix ibm…..eu estava fazendo atualizacao e corrompeu, aperguntae tenho como recuperar essa bando de dados corrompido….

    Responda

  6. Arthur Romano

    Trabalhamos com o Firebird a um tempo e nunca tivemos problemas de corrupção em banco de dados. Temos clientes com bancos com mais de 4gb e tabelas com mais de 18mihlões de registros que são acessadas instantaneamente. Para se ter uma idéia, temos clientes conectados on-line neste banco através de internet (aproximadamente 50 conexões remotas e em torno de 80 conexões locais) e mesmo com a comunicação sendo feita pela internet, nunca tivemos problemas de corrupção, sendo que a velocidade de acesso remoto é bastante aceitável. Firebird é 100% e não tenho do que reclamar.

    Responda

  7. Up Brasil

    Bem estive lendo alguns comentarios sobre o FB, bem sou desenvolvedor desde a versão 4 do delphi e em 99 comecei a utilizar o FB até hj tenho varios sistemas rodando com o FB e NUNK eu disse NUNK me deram nenhum tipo de problemas, recentemente visitei um cliente antigo a base dele ja esta com quase 8GB e rodando como se estivesse acabado de instalar.
    Hoje tenhu uma empresa de desenvolvimento de softwares utilizo JAVA e algumas vezes junto com FB, para mim JAVA+FB esta sendo exelente nada contra outros bancos como DB4O, MYSQL, POSTGREE etc… são exelentes bancos porem pela facilidade ainda continuo prefereindo o FB, e como ja disseram ai em cima cada caso eh um caso, eu particularmente recomendo FB 2.5 inclusive para se utilizar em desenvolvimento web com outras linguagens por ex o PHP…

    Responda

  8. Keferson

    Olá, bom dia! Aqui na empresa foi desenvolvido um software de lista telefônica que utiliza o Firebird. O que está acontecendo é quando vamos nos clientes instalar esse software, e se ele detecta que tem outro firebird na máquina do cliente, logo o nosso software não funciona. Há possibilidade de funcionar 2 firebird em uma máquina, alguma solução?
    Sei que aqui não é forum, mas vi que vocês entendem do assunto.

    Desde já grato.
    Saudações

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Oi Keferson, provavelmente é só mudar a porta.

    Responda

  9. Everton Sales

    Garanta um commit em toda alteração do usuario, assim ao faltar energia, etc, nenhum buffer será perdido… e a base sempre estará ok.

    Responda

  10. Lairdevilson José Fiumane

    Pessoal, trabalho num empresa onde o banco é utilizado desde o Interbase hoje o Firebird, problemas de corrupções já ocorreram, mais por problemas de queda de energia, como alguns disseram acima, coloque um banco Oracle num servidor que muitos usam o Firebird e vejam também o resultado, dai façam o teste ao contraio coloque o Firebird num servidor onde se roda o Oracle e depois vocês venham falar.

    Aqui na empresa temos dezenas de clientes, temos banco com mais de 20 gigas e sem problemas, tudo depende de como foi montado seu banco, e as consultas que fazem, não adianta tem um banco Oracle seu o programador não souber programar.

    Trabalho com Firebird há anos e não tenho o que reclamar, e quem utilizam o IBEXPERT então está no céu.

    Como já ouvi antes e vou passar a diante, o melhor banco de dados é aquele que você sabe usar, não adianta tem uma Ferrari se você não souber liga-la.

    Não critiquem o Firebird se você não o conhecem, ele não é o melhor que o MS-SQL e o ORACLE, mais não perde nada para o PostgreSQL e o MySQL, cada um tem se valor.

    Quem critica o Firebird com certeza não sabe programar.

    Abraços..

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Assino embaixo cada uma das suas palavras.

    Bacana a experiência: mais de 20 Gb com o Firebird? E como ele se comporta neste caso? Bem?

    Também sou fã deste SGBD :)

    Responda

    Lairdevilson José Fiumane Reply:

    Boa tarde!

    Olha tudo é relativo, claro que ficasse mais lento, mais um desempenho muito bom.
    Estamos desenvolvendo agora o log Externo para retirarmos os logs do banco principal.

    Aprovado Firebird com banco de 24,3 Gigas, com mais de 30 conexões.

    abraços…

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Interessantíssima esta sua experiência, porque vai diretamente contra o argumento de que os bancos de dados Firebird são fácilmente corrompíveis.

    No caso, você fez um particionamento dos bancos de dados? Como foi a estratégia adotada? Ele simplesmente evoluiu pra chegar a este tamanho?

    Responda

    Lairdevilson José Fiumane Reply:

    Hoje está em apenas um banco, mais já começamos a migra para 2 bancos em alguns clientes.
    Apenas utilizamos o banco secundário para log, O log foi o maior causador do crescimento do banco, devido nosso sistema ter que ter os log de tudo que se faz o banco cresceu demais, agora como convertemos para o 2.5 estamos utilizando o comando “EXECUTE STATEMENT…..ON EXTERNAL” assim o banco mesmo controla os logs.

    qualquer duvida…

    abracos…

    Responda

  11. Carlos Daniel

    Trabalho com programação desde 1988, sou da época dos antigos banco de dados tipo “flat table”, passei pelo dBase, Paradox, Interbase 6 e hoje estou com o Firebird desde a versão 1.0 e posso dizer que em um universo de 300 cópias distribuidas tive 2 ou 3 problemas, que foram na verdade causados por falhas de HD no cliente.

    Também temos um sistema rodando em PHP com base de dados Firebird, em um servidor Windows com XAMPP, já roda a uns 2 meses sem qualquer incidente, embora deva confessar que é algo de nossa intranet e com baixo volume de acesso.

    Para quem usa o Firebird em aplicações criticas sabe que o rodar ele em um servidor Linux com RAID 0(espelhado) nem sequer afeta o desempenho. Um outro ponto que gostaria de destacar do Firebird é sua estabilidade em base de dados com armazenamento de arquivos binários, mais particularmente fotos no meu caso. Base de 3 GBytes sem qualquer sinal de problemas, rodando backup com os aplicativos cliente conectados e um fbserver.exe consumindo um máximo de 7% de processador… honestamente amigos, não vejo nenhum opção melhor, pelo menos entre os open source ou freeware que seja!!

    Abraços

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Mais um belo exemplo de uso do Firebird. Valeu por compartilhar.

    É após ouvir casos como estes que fico intrigado com a pouca popularidade deste SGBD

    Responda

  12. Roberto Carlos

    Aqui na empresa utilizamos o Firebird desde a primeira versão, e desenvolvemos o ERP para gerenciamento de operadora de planos de saúde, (Saúde Online) em .NET e firebird, sendo que hoje temos quase 1000 usuários que acessam o sistema, fora os acessos via webservice que é feito por outras operadoras. O banco está com 10 GB e a perfórmance é fantástica, não trocaria o Firebird por nenhum outro banco de dados cidade, apesar de conhecer todos os outros.

    Responda

  13. Roberto Carlos

    versão, e desenvolvemos o ERP para gerenciamento de operadora de planos de saúde, (Saúde Online) em .NET e firebird, sendo que hoje temos quase 1000 usuários que acessam o sistema, fora os acessos via webservice que é feito por outras operadoras. O banco está com 10 GB e a performance é fantástica, não trocaria o Firebird por nenhum outro banco de dados citados, apesar de conhecer todos os outros.

    Responda

  14. Carlos Antônio Ferreira da Silva

    Temos cerca de 90 clientes espalhados
    na região do SUL de MG,
    todos com servidores simples,
    em sua maior parte sem nobreak até.

    As ÚNICAS VEZES que tivemos corrupções de
    banco de dados foi quando , no momento de um
    BKP/RESTORE, acaba a energia e está ou sem
    nobreak ou com nobreak desligado.

    Observação :
    Trabalhamos com automação comercial e industrial,
    desde fábricas de calçados, fábricas de produtos químicos,
    até farmácias, lojas de roupas, de materiais de construção,
    supermercados e outros…

    Uso praticamente todos recursos que o Firebird nos dá,
    estou usando atualmente a versão 2.1.3

    ABRAÇOS a todos… e quem ler a LISTA
    verá que o FIREBIRD é EXCELENTE
    e verá que quem REALMENTE O USA sabe do que ESTOU FALANDO,
    e não fica analisando “bebês da computação” que
    instalam o FB numa máquina velha , sem no break
    e querem que funcione como um ORACLE numa super máquina…
    Existe isto?????

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Belos pontos.

    Responda

  15. Vinícius

    O grande problema que encontrei no firebird são que quem criou o banco que eu usava não se atualizou e criou um banco muito ruim, em uma versão antiga do próprio firebird. O que torna a maioria das tecnologias ruims é quem as usa.

    Responda

  16. Meuzi Eduardo

    O Firebird é um caso de amor antigo. Impossível mudar.

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Concordo :)

    Responda

  17. Evandro Blesa

    Olá galera… parabéns pela discursão sobre o firebird, gostaria de uma ajuda suas, trabalho com um sistema para emissão de cupom fiscal da Digisat o SG4, e o SGBD é Firebird 2.3, só que o sistema vive corrompendo do nada, não há queda de energia, não há nada instalado no computador somente o antivírus que o Avast versão free, e já não o que faço mais. Vocês poderiam me dá uma ajuda no que fazer para tentar achar o problema na máquina ou até mesmo no programa? Obrigado a todos…

    Responda

    Edemar Reply:

    Reveja as dependências do seu banco, já faz tempo, mas caso ainda tenha o problema, pode me encaminhar a estrutura do banco, que eu vejo o motivo.

    Responda

  18. Michael

    Ele é impopular porque é ruim.

    Confiabilidade zero (tem mais corrupção que o Congresso Nacional), impossibilidade de backup quente, incapacidade de gerenciar tabelas com mais de 5 milhões de registros (performance pífia), existência de bugs tenebrosos na aplicação de constraints…

    Responda

    Bernardo Martins Reply:

    Se não sabe o que fala, o melhor é ficar calado.

    Responda

    Edemar Reply:

    Programador de Excel, acha que sabe programar, não faz um vinculo no banco de dados, nem sabe o que é uma FK, e diz que o banco que é ruim, vergonhoso.

    Responda

    Bruno Bueno Reply:

    Edemar, você não sabe do que tá falando, o Firebird tem todas essas tristes características que o Michael falou. Seu putinho que faz cocô com cheiro de lágrimas de pônei com câimbra!
    Só te digo uma coisa: Bicicreta!!

    Responda

  19. Joel

    Utilizo o Firebird ( 1.0 e 2.1 ) ha 12 anos com sucesso.
    Tenho por volta de 500 base de dados instaladas.
    Servidores variam entre WIN XP, WIN 7, WINServer 2003, WINServer 2008 e várias distruições linux ( Debian, Fedora, CentOS, Red Hat, Ubuntu ).
    A menor base gira em torno de 100MB e a maior em torno de 8GB.
    Desempenho, para o meu tipo de aplicativo que é contábil, está ótimo.
    Utilizo Delphi 6 e 2010 com IBO.
    Corrupção zero.
    Agora, infelizmente, tenho que concordar com o artigo. Tenho tentando desenvolver alguns aplicativos em python e mono e neste mundo o Firebird não tem vez. Mesmo com as opções de acesso citadas acima. Já testei fdb python e este não é tão prático quanto o psycopg2. Neste momento estamos testando o mono e percebemos que o driver para firebird, também, é menos prático que o driver para Firebird. Estou sou um dos patrocinadores do Firebird, gosto muito dele, mas tenho tido dificuldades em mantê-los em meus novos projetos, fora do mundo delphi.

    Responda

  20. Mariana

    Meu primeiro contato com bancos de dados foi através do Firebird e logo em seguida o utilizei no meu primeiro emprego por 3 anos até que a empresa resolveu substituí-lo pelo SQL Server. Também nunca entendi porque ele não é utilizado fora de aplicações em Delphi, é um ótimo bd e extremamente simples de ser utilizado, como dito no artigo, especialmente pelo fato do bd ser um único arquivo. Hoje em dia se você menciona Firebird, sofre inclusive bullyng nas empresas por ser “arcaico”, injustamente na minha opinião.

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Exatamente. E se tem algo que ele NÃO é, é arcaico.

    Responda

  21. Mauricio Zaccaro

    Bom Dia, gente lendo aqui entre prós e contras do Firebird já há alguns dias, resolvi então utilizá-lo, No entanto, estou enfrentando um problema MUITO MUITO chato. A lentidão do Firebird!!! Não sei se é normal mais vejam. Eu estava a fazer diversos testes e todas me retornavam resultados pouco interessantes, então resolvi testar uma “corrida” entre Firebird VS Access, fiz o seguinte:

    OBS.: Ambos com Drive ODBC, conexão ADO e instruções SQL ( tudo igual, mudando apenas de banco pra banco )

    Fiz um Banco em Access(.MDB) e um em Firebird ( .FDB ) com a tabela CIDADES, onde cadastrei todas as cidades do Brasil, cerca de 10.200 ( Dez mil e duzentos ) registros. Criei um formulário simples com 2 botões ( um pra carregar o Access e um para carregar o Firebird) e uma ListView, onde carregava as 10.200 cidades.

    Com o Access ao clicar no botão, o Listview carregou em aproximadamente 1 (um) segundo, o que eu achei um bom resultado. Já com o Firebird, para se carregar todos os Dez mil e duzentos registros de cidades cadastradas no mesmo na Listview, o programa demorou aproximadamente 15 minutos. Isso mesmo que vocês leram, 15 minutos para se carregar meros 10 mil registros. Absurdo, sem nexo algum essa demora, visto que os drives são os mesmos, o computador , S.O, linguagem ( vb6 ), tipo de conexão, tudo, tudo e tudo são iguais. Fiz e refiz os testes com outros tipos de conexões diversas e diversas vezes, ainda assim os resultados foram sempre os mesmos, o Access em 1 segundo e o Firebird em 15 minutos ( de média ).

    É isso gente, minha primeira impressão sobre o Firebird foi péssima. Gostaria que vocês me falassem ai, se é normal essa lentidão, se existe algo sobre ele que eu não saíba e que pode melhorar consideravelmente seu desempenho, porque, eu até gostei da facilidade de ingressar ele no setup, utilizando o IBExpert ficou fácil manusear o Banco e tudo mais, só que, é essa velocidade de “lesma” que é o problema. Se tiverem alguma luz, por favor, sou todo ouvido ( olhos ). No mas, Obrigado!

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Oi Maurício, tem alguma coisa bem errada no seu teste, por que esta velocidade tornaria inviável a adoção do Firebird em qualquer projeto, o que não é o caso.

    Responda

    Mauricio Zaccaro Reply:

    Pois é, eu até compilei o projeto pensando que mudaria algo, mais continua a mesma lerdeza. Não sei o que é, pois até mesmo simples consultas ( ex.: retornar um cliente qualquer em um registro de 1000 “mil” clientes), que o Access faz em “um piscar de olhos” o Firebird me retorna o mesmo resultado em 3 a 4 segundos, isto com o BD já aberto, se for abrir/fechar a cada nova instrução leva quase 8 segundos. Sinceramente, ainda não entendi o que está acontecendo, em uma outra pagina, me disseram para não usar o ODBC mais, baixar o Provider .NET ( esse “ponto” me deixa confuso se irá funcionar com VB6 ), enfim, vou fazer os testes amanha. Não vou desistir do Firebird tão rápido. De toda forma, obrigado por responder.

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    É no mínimo curioso.

    Trabalhei com o Firebird quase uns dez anos atrás migrando um aplicação baseada em MS Access para ele.

    Um dos motivadores foi justamente o ganho de desempenho. É o tal negócio: o Firebird não é nem de longe um dos mais rápidos, mas também não é tãaaaaao lento assim. :)

    Responda

    Marco Reply:

    olha o plano de execução do SQL, é o tipico caso de falta de índice. O Access coloca automaticamente os indices e o Firebird por ser SQL puro nao.

    Responda

  22. gabriel

    Gosto muito do firebird, a compatibilidade com padrões SQL é ótima, recurso de conexão interbancos também é muito interessante, tratamento de caracteres, muito fácil de trabalhar, mas, o firebird tem uma falha na parte da segurança que, torna inviável a aplicação dele em grandes projetos: ACESSO DE USUARIO!

    Gosto da filosofia de criar procedures, triggers, …, enfim, centralizar as regras de negocio em banco. O custo para manutenção é inferior, a velocidade para implementações e reaproveitamento é maior e etc. Mas, a partir do momento em que qualquer um pode copiar o arquivo .FDB para outra máquina é abrir o modelo com a senha padrão, é ridículo!
    Não é barato você colocar a segurança de acesso ao banco na infraestrutura, requer politicas de segurança, acesso na rede, S.O. próprio para servidores, domínios, e tudo mais.

    E o pior:
    Toda senha do firebird suporta no em seu máximo 8 caracteres!!
    A senha “masterkey” contem 9 caracteres, façam o teste de locar apenas com “masterke” e postem ai o resultado!!

    Responda

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.