Firebird com linux 64 bits
Ricardo Esdra
no VOL e não obtive resultados ainda.
Estou tendo problemas com o firebird 2.0 e também com o 2.1, com linux
64 bits, já tentei diversas vezes instalar um banco no servidor, que o
mesmo que uso para fazer instalações em windows e linux 32 bits e vai
normal.
Agora o estranho é que quando uso 64 bits eu recebo uma mensagem "is not
a valid data base", e isto sempre me acontece quando tento instalar o
sistema em alguma máquina com 64 bits, no windows eu nunca testei pois
ainda não tivemos nenhum cliente com windows nesta arquitetura.
Este erro eu recebo ao tentar usar gfix, gbak, ibexpert pelo terminais
windows, flamerobin no linux, e ao tentar abrir o sistema, e seu eu
copiar esta mesma base que dá este erro do linux 64 para wndows ou linux
32 bits roda normal, o que me leva a imaginar que possa ser algo
relacionado ao 64 bits e o modo como o banco foi criado, pois ao tentar
criar um banco do zero no flamerobin ele aceita a conexão normalmente.
já testei tanto com ubuntu quanto debian,
desde já agradeço a todos.
--
##############################################
# Ricardo Esdra #
# #
# linux user n° 446011 #
##############################################
--
To UNSUBSCRIBE, email to debian-user-por...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
hamacker
banco de dados num firebird 64bits.
Isso provavelmente resolverá seu problema.
Nunca, mas ouça bem : "Nunca use a mesma base de dados em versões de
banco de dados diferentes."
Por não sabermos o que mudou de uma versão para outra, não vamos
arriscar corromper a base.
2009/9/1 Ricardo Esdra <rie...@gmail.com>:
Ricardo Esdra
> Fa�a o backup de sua base de dados no sistema 32bits, e restaura o
> banco de dados num firebird 64bits.
> Nunca, mas ou�a bem : "Nunca use a mesma base de dados em vers�es de
> banco de dados diferentes."
> Por n�o sabermos o que mudou de uma vers�o para outra, n�o vamos
> arriscar corromper a base.
>
> 2009/9/1 Ricardo Esdra <rie...@gmail.com>:
>
>> Boa noite pessoal, eu ja andei procurando no google, postando no orkut no
>>
>> Estou tendo problemas com o firebird 2.0 e tamb�m com o 2.1, com linux 64
>> bits, j� tentei diversas vezes instalar um banco no servidor, que o mesmo
>> que uso para fazer instala��es em windows e linux 32 bits e vai normal.
>> Agora o estranho � que quando uso 64 bits eu recebo uma mensagem "is not a
>> valid data base", e isto sempre me acontece quando tento instalar o sistema
>> tivemos nenhum cliente com windows nesta arquitetura.
>> Este erro eu recebo ao tentar usar gfix, gbak, ibexpert pelo terminais
>> windows, flamerobin no linux, e ao tentar abrir o sistema, e seu eu copiar
>> roda normal, o que me leva a imaginar que possa ser algo relacionado ao 64
>> bits e o modo como o banco foi criado, pois ao tentar criar um banco do zero
>>
>> j� testei tanto com ubuntu quanto debian,
>>
>> desde j� agrade�o a todos.
>>
>> --
>> ##############################################
>> # Ricardo Esdra #
>> # #
>> # linux user n� 446011 #
>> ##############################################
>>
>>
>> --
>> To UNSUBSCRIBE, email to debian-user-por...@lists.debian.org
>> with a subject of "unsubscribe". Trouble? Contact
>> listm...@lists.debian.org
>>
>>
>>
>
>
windows via gbak, e d� erro;
ricardo@woofer:~/Desktop/firebird$ gbak -V -R -u sysdba -p masterkey
cadastro.fbk /home/ricardo/cadastro.fdb
gbak: ERROR:expected page size, encountered "masterkey"
gbak:Exiting before completion due to errors
e direto dentro do flamerobin eu tentei extrair um metadata que eu tinha
feito no ibexpert, pelo run query, ele
extrai sem erros, mas ao tentar dar um "select * from tabela" com o
banco carregado j�, ele n�o me retorna os
dados contidos da tabela.
ao fazer o backup no windows eu sei a op��o gbak -g -b -z -v -l, e para
restaurar normalmente eu uso gbak -v -r
mas no linux eu tentei e n�o vai, da o erro que postei acima, e ao
tentar rodar a op��o export ISC_USER = SYSDBA,
me d� este erro,
woofer:/home/ricardo/Desktop/firebird# export ISC_USER = SYSDBA
bash: export: `=': not a valid identifier
o mesmo erro acontece ao tentar rodar o comando como usu�rio comum.
se tiver alguma ideia.
hamacker
O que voce pode fazer é, usando o ibexpert extrair o máximo que puder
do metadados de todas as tabelas (individualmente), salvar as
storeds/triggers e afins.
Instalar um banco de dados 64bits, criar um banco novo e reaplicar o
script, populando as tabelas e recriando os objetos.
O que provavelmente ocorreu foi que voce usou por algum tempo uma
versão nova (2.1), com o banco de dados (.fdb) da versão velha(2.0),
embora não tenha dado erro a principio, os novos dados foram populados
do jeito "novo" sob uma estrutura velha. Leia a CHANGELOG das duas
versões e veja se a versão mais recente mudou a versão do GDS
(estrutura de tabelas de sistemas), se isso aconteceu de uma versão
para a outra, voce nunca poderia ter reutilizado a mesma base.
Evite usar o frontends que mexem diretamente nas tabelas de sistemas,
no começo eu percebí que o ibexpert para algumas operações ao invés de
comandos SQL para fazer alterações estruturais ele simplesmente
editava diretamente as tabelas de sistemas, se ainda for assim para
algumas operações ele próprio pode ter corrompido sua base.
[]'s e sucesso.
2009/9/1 Ricardo Esdra <rie...@gmail.com>:
> hamacker escreveu:
>>
>> Faça o backup de sua base de dados no sistema 32bits, e restaura o
>> banco de dados num firebird 64bits.
>> Isso provavelmente resolverá seu problema.
>> Nunca, mas ouça bem : "Nunca use a mesma base de dados em versões de
>> banco de dados diferentes."
>> Por não sabermos o que mudou de uma versão para outra, não vamos
>> arriscar corromper a base.
>>
>> 2009/9/1 Ricardo Esdra <rie...@gmail.com>:
>>
>>>
>>> Boa noite pessoal, eu ja andei procurando no google, postando no orkut no
>>> VOL e não obtive resultados ainda.
>>>
>>> Estou tendo problemas com o firebird 2.0 e também com o 2.1, com linux 64
>>> bits, já tentei diversas vezes instalar um banco no servidor, que o mesmo
>>> que uso para fazer instalações em windows e linux 32 bits e vai normal.
>>> Agora o estranho é que quando uso 64 bits eu recebo uma mensagem "is not
>>> a
>>> valid data base", e isto sempre me acontece quando tento instalar o
>>> sistema
>>> em alguma máquina com 64 bits, no windows eu nunca testei pois ainda não
>>> tivemos nenhum cliente com windows nesta arquitetura.
>>> Este erro eu recebo ao tentar usar gfix, gbak, ibexpert pelo terminais
>>> windows, flamerobin no linux, e ao tentar abrir o sistema, e seu eu
>>> copiar
>>> esta mesma base que dá este erro do linux 64 para wndows ou linux 32 bits
>>> roda normal, o que me leva a imaginar que possa ser algo relacionado ao
>>> 64
>>> bits e o modo como o banco foi criado, pois ao tentar criar um banco do
>>> zero
>>> no flamerobin ele aceita a conexão normalmente.
>>>
>>> já testei tanto com ubuntu quanto debian,
>>>
>>> desde já agradeço a todos.
>>>
>>> --
>>> ##############################################
>>> # Ricardo Esdra #
>>> # #
>>> # linux user n° 446011 #
>>> ##############################################
>>>
>>>
>>> --
>>> To UNSUBSCRIBE, email to debian-user-por...@lists.debian.org
>>> with a subject of "unsubscribe". Trouble? Contact
>>> listm...@lists.debian.org
>>>
>>>
>>>
>>
>>
>
> eu fiz um teste com o gbak para tentar extrair um backup que gerei no
> windows via gbak, e dá erro;
>
> ricardo@woofer:~/Desktop/firebird$ gbak -V -R -u sysdba -p masterkey
> cadastro.fbk /home/ricardo/cadastro.fdb
> gbak: ERROR:expected page size, encountered "masterkey"
> gbak:Exiting before completion due to errors
>
> e direto dentro do flamerobin eu tentei extrair um metadata que eu tinha
> feito no ibexpert, pelo run query, ele
> extrai sem erros, mas ao tentar dar um "select * from tabela" com o banco
> carregado já, ele não me retorna os
> dados contidos da tabela.
>
> ao fazer o backup no windows eu sei a opção gbak -g -b -z -v -l, e para
> restaurar normalmente eu uso gbak -v -r
> mas no linux eu tentei e não vai, da o erro que postei acima, e ao tentar
> rodar a opção export ISC_USER = SYSDBA,
> me dá este erro,
>
> woofer:/home/ricardo/Desktop/firebird# export ISC_USER = SYSDBA
> bash: export: `=': not a valid identifier
>
> o mesmo erro acontece ao tentar rodar o comando como usuário comum.
>
> se tiver alguma ideia.
>
> --
> ##############################################
> # Ricardo Esdra #
> # #
> # linux user n° 446011 #
> ##############################################
>
>
> --
> To UNSUBSCRIBE, email to debian-user-por...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listm...@lists.debian.org
>
>
Ricardo Esdra
Seu banco já está corrompido.
O que voce pode fazer é, usando o ibexpert extrair o máximo que puder
do metadados de todas as tabelas (individualmente), salvar as
storeds/triggers e afins.
Instalar um banco de dados 64bits, criar um banco novo e reaplicar o
script, populando as tabelas e recriando os objetos.
O que provavelmente ocorreu foi que voce usou por algum tempo uma
versão nova (2.1), com o banco de dados (.fdb) da versão velha(2.0),
embora não tenha dado erro a principio, os novos dados foram populados
do jeito "novo" sob uma estrutura velha. Leia a CHANGELOG das duas
versões e veja se a versão mais recente mudou a versão do GDS
(estrutura de tabelas de sistemas), se isso aconteceu de uma versão
para a outra, voce nunca poderia ter reutilizado a mesma base.
Evite usar o frontends que mexem diretamente nas tabelas de sistemas,
no começo eu percebí que o ibexpert para algumas operações ao invés de
comandos SQL para fazer alterações estruturais ele simplesmente
editava diretamente as tabelas de sistemas, se ainda for assim para
algumas operações ele próprio pode ter corrompido sua base.
[]'s e sucesso.
olha o que ocorre é o seguinte, trabalho uma empresa que desenvolve sistemas para escritório
de contabilidade, o banco que uso ja vem com algumas tabelas populadas, tipo cnae, cbo, e
outros dados, este mesmo banco que dá erro como estando corrompido, se eu copiar ele para
uma máquina com windows ou linux 32 bits, ele não dá erro nenhum .
--
Ricardo Esdra.
hamacker
export ISC_USER=SYSDBA
export ISC_PASSWORD=masterkey
comando para reparar a base de dados (faça uma cópia antes) :
/usr/lib/firebird2/bin/gfix -v -full localhost:/home/databases/admin1.fdb
repare a ausencia de espacos a direita e esquerda do sinal de
igualdade. Note também que as informacoes de conta são case-sensitive,
isto é, maiusculas e minusculas importam. Assim um simples comando de
backup ou restore tem que ter credenciais exatas, ex :
/usr/bin/gbak -t -user "SYSDBA" -password "masterkey"
"192.168.1.14:/onde/esta/meu/banco.fdb" "/media/backup/banco.fbk"
Sintaxe correta do gbak voce encontra aqui :
http://www.destructor.de/firebird/gbak.htm
[]'s e sucesso.
2009/9/1 Ricardo Esdra <rie...@gmail.com>:
> hamacker escreveu:
>>
>> Faça o backup de sua base de dados no sistema 32bits, e restaura o
>> banco de dados num firebird 64bits.
>> Isso provavelmente resolverá seu problema.
>> Nunca, mas ouça bem : "Nunca use a mesma base de dados em versões de
>> banco de dados diferentes."
>> Por não sabermos o que mudou de uma versão para outra, não vamos
>> arriscar corromper a base.
>>
>> 2009/9/1 Ricardo Esdra <rie...@gmail.com>:
>>
>>>
>>> Boa noite pessoal, eu ja andei procurando no google, postando no orkut no
>>> VOL e não obtive resultados ainda.
>>>
>>> Estou tendo problemas com o firebird 2.0 e também com o 2.1, com linux 64
>>> bits, já tentei diversas vezes instalar um banco no servidor, que o mesmo
>>> que uso para fazer instalações em windows e linux 32 bits e vai normal.
>>> Agora o estranho é que quando uso 64 bits eu recebo uma mensagem "is not
>>> a
>>> valid data base", e isto sempre me acontece quando tento instalar o
>>> sistema
>>> em alguma máquina com 64 bits, no windows eu nunca testei pois ainda não
>>> tivemos nenhum cliente com windows nesta arquitetura.
>>> Este erro eu recebo ao tentar usar gfix, gbak, ibexpert pelo terminais
>>> windows, flamerobin no linux, e ao tentar abrir o sistema, e seu eu
>>> copiar
>>> esta mesma base que dá este erro do linux 64 para wndows ou linux 32 bits
>>> roda normal, o que me leva a imaginar que possa ser algo relacionado ao
>>> 64
>>> bits e o modo como o banco foi criado, pois ao tentar criar um banco do
>>> zero
>>> no flamerobin ele aceita a conexão normalmente.
>>>
>>> já testei tanto com ubuntu quanto debian,
>>>
>>> desde já agradeço a todos.
>>>
>>> --
>>> ##############################################
>>> # Ricardo Esdra #
>>> # #
>>> # linux user n° 446011 #
>>> ##############################################
>>>
>>>
>>> --
>>> To UNSUBSCRIBE, email to debian-user-por...@lists.debian.org
>>> with a subject of "unsubscribe". Trouble? Contact
>>> listm...@lists.debian.org
>>>
>>>
>>>
>>
>>
>
> eu fiz um teste com o gbak para tentar extrair um backup que gerei no
> windows via gbak, e dá erro;
>
> ricardo@woofer:~/Desktop/firebird$ gbak -V -R -u sysdba -p masterkey
> cadastro.fbk /home/ricardo/cadastro.fdb
> gbak: ERROR:expected page size, encountered "masterkey"
> gbak:Exiting before completion due to errors
>
> e direto dentro do flamerobin eu tentei extrair um metadata que eu tinha
> feito no ibexpert, pelo run query, ele
> extrai sem erros, mas ao tentar dar um "select * from tabela" com o banco
> carregado já, ele não me retorna os
> dados contidos da tabela.
>
> ao fazer o backup no windows eu sei a opção gbak -g -b -z -v -l, e para
> restaurar normalmente eu uso gbak -v -r
> mas no linux eu tentei e não vai, da o erro que postei acima, e ao tentar
> rodar a opção export ISC_USER = SYSDBA,
> me dá este erro,
>
> woofer:/home/ricardo/Desktop/firebird# export ISC_USER = SYSDBA
> bash: export: `=': not a valid identifier
>
> o mesmo erro acontece ao tentar rodar o comando como usuário comum.
>
> se tiver alguma ideia.
>
> --
> ##############################################
> # Ricardo Esdra #
> # #
> # linux user n° 446011 #
> ##############################################
>
>
> --
> To UNSUBSCRIBE, email to debian-user-por...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listm...@lists.debian.org
>
>
hamacker
pelo que entendí de mensagens passadas, o backup não estava dando
certo.
Então teste novamente, veja a sintaxe correta. Se o backup realmente
não puder ser concretizado e não é um erro de sintaxe então por
eliminação, o banco de dados está corrompido. Note que não estou
pedindo para fazer backup na plataforma que não funciona, ao
contrário, o backup tem de ser feito na plataforma que funciona.
[]'s
2009/9/2 Ricardo Esdra <rie...@gmail.com>:
> olha o que ocorre é o seguinte, trabalho uma empresa que desenvolve sistemas
> para escritório
> de contabilidade, o banco que uso ja vem com algumas tabelas populadas, tipo
> cnae, cbo, e
> outros dados, este mesmo banco que dá erro como estando corrompido, se eu
> copiar ele para
> uma máquina com windows ou linux 32 bits, ele não dá erro nenhum .
>
>
> --
> Ricardo Esdra.
>
Ricardo Esdra
Se ele não dá problema algum entao voce conseguiria fazer o backup, e
pelo que entendí de mensagens passadas, o backup não estava dando
certo.
Então teste novamente, veja a sintaxe correta. Se o backup realmente
não puder ser concretizado e não é um erro de sintaxe então por
eliminação, o banco de dados está corrompido. Note que não estou
pedindo para fazer backup na plataforma que não funciona, ao
contrário, o backup tem de ser feito na plataforma que funciona.
[]'s
então para testar é só lá em casa na parte da noite, aqui na empresa não temos linux 64 bits
o comando do export me dava erro mas pode ser por causa dos espaços antes e depois do
sinal de "=", ai eu sava as opções de usuário e password direto no comando, a questão do
sysdba / SYSDBA, no flamerobin onde eu faço o teste na parte gráfica na minha máquina ele
tanto faz ser usado minúsculo ou maiúsculo.
sim a questão do backup [gbak] não funcionar, no linux por estar com a base corrompida, eu
posso pegar esta base e jogar em pen drive e dpois jogar em uma com linux ou windows 32
que ela funciona, isto que eu acho estranho.
--
Ricardo Esdra.
hamacker
Faça o backup na base que está OK, se voce conseguir não há nada de
errado com ela, ok ?
Mas se voce não consegue fazer backup dela, mesmo os sistemas
funcionando OK significará que a base tá corrompida.
Uma base corrompida pode funcionar por algum tempo, mas dará problema
mais cedo ou mais tarde.
Tente o gfix como eu passei antes de realizar a operação de backup,
alguns sinistros ele pode consertar.
2009/9/2 Ricardo Esdra <rie...@gmail.com>:
> sim a questão do backup [gbak] não funcionar, no linux por estar com a base
> corrompida, eu
> posso pegar esta base e jogar em pen drive e dpois jogar em uma com linux ou
> windows 32
> que ela funciona, isto que eu acho estranho.
>
> --
> Ricardo Esdra.
>
Ricardo Esdra
Olha,
Faça o backup na base que está OK, se voce conseguir não há nada de
errado com ela, ok ?
Mas se voce não consegue fazer backup dela, mesmo os sistemas
funcionando OK significará que a base tá corrompida.
Uma base corrompida pode funcionar por algum tempo, mas dará problema
mais cedo ou mais tarde.
Tente o gfix como eu passei antes de realizar a operação de backup,
alguns sinistros ele pode consertar.
> sim a questão do backup [gbak] não funcionar, no linux por estar com a base
> corrompida, eu
> posso pegar esta base e jogar em pen drive e dpois jogar em uma com linux ou
> windows 32
> que ela funciona, isto que eu acho estranho.
>
> --
> Ricardo Esdra.
>
eu fiz o backup ontem, e os erros só dá na hora de restaurar, na hora em que faço o backup
aqui não da erro, mas vou fazer hoje de novo aqui no windows e restaurar la em casa no debian.
--
Ricardo Esdra.
Ricardo Esdra
> Olha,
>
> Fa�a o backup na base que est� OK, se voce conseguir n�o h� nada de
> errado com ela, ok ?
> funcionando OK significar� que a base t� corrompida.
> Uma base corrompida pode funcionar por algum tempo, mas dar� problema
> mais cedo ou mais tarde.
>> corrompida, eu
>> posso pegar esta base e jogar em pen drive e dpois jogar em uma com linux ou
>> windows 32
>> que ela funciona, isto que eu acho estranho.
>>
>> --
>> Ricardo Esdra.
>>
>>
>
>
noite e nada feito,
deu o mesmo erro que passei antes, la na empresa antes de gerar o backup
eu passei
o gfix e n�o d� erro nenhum, e quando tento restaurar aqui d� os erros
que j� passei
antes, muito estranho isto.
--
##############################################
# Ricardo Esdra #
# #
# linux user n� 446011 #
##############################################
Ricardo Esdra
Não fique grilado, isso já aconteceu comigo usando o ibexpert que
mexeu nas tabelas de sistema, e o software de backup tenta recriar uma
situação que não poderia existir e capota.
Por exemplo, mudar NULL para NOT NULL via alguns frontends visuais é
totalmente possivel (pois eles mexem na tabela de sistema), no
entanto, se houverem dados com NULL nessa tabela embora
sistematicamente os programas funcionem, o software de backup não
conseguirá restaurar os dados porque não poderia haver dados NULL no
backup se o campo para onde ele seria transferido não permite essa
operação, é uma inconsistencia entre as tabelas de sistema e o que de
fato estão nas tabelas.
Não sei se consegui explicar direito.
Eu sugiro a voce que pegue essa base de dados, use o IBEXPERT para
gerar os scripts DDL e crie uma base nova e aplique o script DDL, isso
recriará todos os objetos. A seguir voce peça ao ibexpert gerar um
script dos dados, tabela por tabela e faça a mesma coisa, assim que
voce terminar todas as transferencias e tiver tudo 100% conferido faça
a substituição da base antiga pela nova. É bem provavel que com esse
método voce descubra qual a tabela que tá com inconsistencias.
Um pecado capital do Firebird é não permitir restaurar objetos
individualmente, pois isso simplificaria muito a solução.
[]'s e sucesso.
2009/9/2 Ricardo Esdra <rie...@gmail.com>:
> hamacker escreveu:
>>
>> Olha,
>>
>> Faça o backup na base que está OK, se voce conseguir não há nada de
>> errado com ela, ok ?
>> Mas se voce não consegue fazer backup dela, mesmo os sistemas
>> funcionando OK significará que a base tá corrompida.
>> Uma base corrompida pode funcionar por algum tempo, mas dará problema
>> mais cedo ou mais tarde.
>> Tente o gfix como eu passei antes de realizar a operação de backup,
>>> sim a questão do backup [gbak] não funcionar, no linux por estar com a
>>> base
>>> corrompida, eu
>>> posso pegar esta base e jogar em pen drive e dpois jogar em uma com linux
>>> ou
>>> windows 32
>>> que ela funciona, isto que eu acho estranho.
>>>
>>> --
>>> Ricardo Esdra.
>>>
>>>
>>
>>
>
> olha tentei restaurar o backup feito na empresa aqui em casa agora a noite e
> nada feito,
> deu o mesmo erro que passei antes, la na empresa antes de gerar o backup eu
> passei
> o gfix e não dá erro nenhum, e quando tento restaurar aqui dá os erros que
> já passei
> antes, muito estranho isto.
>
> --
> ##############################################
> # Ricardo Esdra #
> # #
> # linux user n° 446011 #
> ##############################################
>
>
> --
> To UNSUBSCRIBE, email to debian-user-por...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listm...@lists.debian.org
>
>
eu ja tentei usar a opção extract metadatas, e rodei o run query no flamerobin depois, aqui na empresa, eu faço este teste, gerando o metadata no ibexpert e restaurando via run query no flamerobin, e da certo, quando tento executar esta query lá em casa que é onde esta instalado o debian 64 bits para fazer o teste, ele roda sem dar erros aparentemente, monta o banco no flamerobin, mas não mostra os dados das tabelas inicias populadas.
Ricardo Esdra.
hamacker
mexeu nas tabelas de sistema, e o software de backup tenta recriar uma
situação que não poderia existir e capota.
Por exemplo, mudar NULL para NOT NULL via alguns frontends visuais é
totalmente possivel (pois eles mexem na tabela de sistema), no
entanto, se houverem dados com NULL nessa tabela embora
sistematicamente os programas funcionem, o software de backup não
conseguirá restaurar os dados porque não poderia haver dados NULL no
backup se o campo para onde ele seria transferido não permite essa
operação, é uma inconsistencia entre as tabelas de sistema e o que de
fato estão nas tabelas.
Não sei se consegui explicar direito.
Eu sugiro a voce que pegue essa base de dados, use o IBEXPERT para
gerar os scripts DDL e crie uma base nova e aplique o script DDL, isso
recriará todos os objetos. A seguir voce peça ao ibexpert gerar um
script dos dados, tabela por tabela e faça a mesma coisa, assim que
voce terminar todas as transferencias e tiver tudo 100% conferido faça
a substituição da base antiga pela nova. É bem provavel que com esse
método voce descubra qual a tabela que tá com inconsistencias.
Um pecado capital do Firebird é não permitir restaurar objetos
individualmente, pois isso simplificaria muito a solução.
[]'s e sucesso.
2009/9/2 Ricardo Esdra <rie...@gmail.com>:
> hamacker escreveu:
>>
>> Olha,
>>
>> Faça o backup na base que está OK, se voce conseguir não há nada de
>> errado com ela, ok ?
>> Mas se voce não consegue fazer backup dela, mesmo os sistemas
>> funcionando OK significará que a base tá corrompida.
>> Uma base corrompida pode funcionar por algum tempo, mas dará problema
>> mais cedo ou mais tarde.
>> Tente o gfix como eu passei antes de realizar a operação de backup,
>> alguns sinistros ele pode consertar.
>>
>> 2009/9/2 Ricardo Esdra <rie...@gmail.com>:
>>
>>>
>>> sim a questão do backup [gbak] não funcionar, no linux por estar com a
>>> base
>>> corrompida, eu
>>> posso pegar esta base e jogar em pen drive e dpois jogar em uma com linux
>>> ou
>>> windows 32
>>> que ela funciona, isto que eu acho estranho.
>>>
>>> --
>>> Ricardo Esdra.
>>>
>>>
>>
>>
>
> olha tentei restaurar o backup feito na empresa aqui em casa agora a noite e
> nada feito,
> deu o mesmo erro que passei antes, la na empresa antes de gerar o backup eu
> passei
> o gfix e não dá erro nenhum, e quando tento restaurar aqui dá os erros que
> já passei