Como eu já havia dito antes, o programa com base de dados incorporada roda
legalzinho, o problema é a seguraça dos dados, ai resolvi migrar para um
banco externo. Na micraçao preciso manipular tabelas inteiras e fazer com
que o formato do hsqldb seja entendido pelo formato do novo banco, o que nem
sempre é facil. A melhor forma de não ter conflito de tipos é utilizar os
dados em estado bruto, tipo csv ou txt. Já tenho todas as tabelas separadas
em arquivos cvs, mas quem disse que consigo importalas facilmente?
principais problemas
datas
campos sem dados
integridade referencial devido a falha da modelagem do banco antigo (tinha
uma tabela de cores, e código das cores, mas estava sendo armazenada o nome
da cor digitada pelo usuário... já corrigi isto
diferenças de sintaxe
também estou com problemas com o campo text(varchar) - limitado em 25
caracteres, vem um outro valor bem alto setado e não consigo alterar (deve
ser algum bug do libreoffice com bancos externos, pois o mesmo aconteceu com
o banco h2.
Para tabelas pequenas fiz uma gambiarra, gerando uma mala direta com os
dados do campo em um documento com a instrução insert, funciona direitinho
agora estou quebrando a cabeça para fazer a importação para os arquivos do
postgresql utilizando os arquivos csv.
Acho que vou parar de brigar com o libreoffice na importação das tabelas e
vou fazer as importações via pgadmin3 ou outra ferramenta do postgresql,
para ver como fica o problema das variaveis quando o banco for lido pelo
libreoffice. Manipular a importação de tabelas fora do ambiente do
libreoffice parece ser a solução. Depois eu conto que bicho que deu...rs
Em 29 de agosto de 2011 22:26, sp24horas <sp24horas@gmail.com> escreveu:
Olá!
Concordo que para coisas maiores é mais seguro trabalhar com outros BDs,
tipo
Oracle, DB2, Interbase, PostgreSQL, MySQL (meu preferido),etc.
Mas, fiquei curioso com a questão de que meros 50 Mb de dados no Base
pudesse causar grandes problemas e resolvi fazer algumas experiências.
Como no meu trabalho estamos pensando em fazer uso mais intensivo do Base e
temos que lidar com BDs com tamanhos bem maiores, procurei gerar um teste
com um milhão de registros e ver o comportamento.
Gerei os scripts e alimentei o bd usando o databasemanager do próprio
arquivo hsqldb.jar.
Por limitação de memória, acabei fazendo os inserts em blocos de 100 mil
registros de 03 campos.
Perdi o trabalho algumas vezes, mas por desconhecer que isso decorre da
falta de um correto shutdown, mau uso da ferramenta .(experimentei o
sqltools do hsqldb também) e gerenciamento de memória da JVM.
Aliás, isso pode corromper até mesmo tabelas de outros bds.
Resumindo, gerei um arquivo .odb com 40 Mb, com formulários padrões e está
funcionando bem.
Consegui varrer uma tabela usando um filtro de 10 mil linhas, sem
problemas.
Com 30 mil, o desempenho no meu notebook já começou a degradar, mas claro
que isso é impensável para quem trabalha com esse volume de dados. Nem
imagine querer carregar todos os registros... out of memory, com certeza.
Como já comentou alguém, ao lidar com tabelas deste tamanho, temos sempre
que limitar a qtde de registros que são necessárias para aquele momento. Ou
seja fazer bom uso dos filtros e selects. Fazer uso de limits.
Apenas para citar: No manual do hsqldb, o limite da tabela é de 2GB e o
size
*limit* of an *HSQLDB* database is 16GB (by default) for all CACHED tables.
Assim, nem sempre a culpa deve ser toda do hsqldb. Pode ser, às
vezes, necessária uma revisão no projeto para que ele possa continuar
atendendo bem.
Em 26 de agosto de 2011 18:30, rogerio dandrea <rolemosda@gmail.com
escreveu:
Concordo com voce, para projetos grandes nem pensar...
O fato é que a base de dados original surgiu no access a mais de 10 anos,
agora estou com este elefante Branco no meio da sala e não é o
postgre...rs
Alem do mais 50mb é um banquinho de dados, e nestas indas e vindas estou
aprendendo um bucado sobre banco de dados e corrigindo erros do banco de
dados(erros de concepção).
Acabei de instalar a versão 9, vamos ver que bicho que dá...rs Conto com
suas dicas :0)
1 pergunta qual o meio mais rapido de migrar do base para o postgree?
arquivos cvs?
Em 26 de agosto de 2011 17:51, Rogerio Luz Coelho
<luz.rogerio@gmail.com>escreveu:
Quem usar o Base como BD para grandes empreendimentos é RETARDADO ...
desculpa isso quem falou não fui eu e sim um dos caras para quem
perguntei
porque tinha tanta briga com esse componente.
Vai de Postgres e fim ... se como front-end o Base funcionar melhor,
mas
se
nem isso dá certo ... estarei abandonando a ideia de aprender a mexer
com
ele no futuro.
Meu problema é que ele vem instalado com o LibO então funciona nas
máquinas
que eu tenho acesso para fazer meu BD de pacientes / programas, mas
para
um
troço de 50Mb ?? acho que não é para ser ...
Rogerio
Em 24 de agosto de 2011 20:20, MarioSergio
<mariosergiofigueira@gmail.com>escreveu:
Em 24/08/2011 19:23, Noelson Duarte escreveu:
Olá,
Em 24 de agosto de 2011 11:38, rogerio dandrea<rolemosda@gmail.com
**
escreveu:
Quer fazer um teste simples, abra um banco de dados grande(pode ser
na
versão 3.3.4) e na visualização da tabela role a tela para baixo.
pronto
a
tela fica acinzentada e você fica travado ate o programa reagir...
não
tem
nada a ver com macros, mas Voce não pode se esquecer que o motor do
libreoffice base é o hsqldb 1.8 - 100% JAVA.
Salvo engano, o "driver" HSQLDB nativo do BASE foi totalmente
reescrito
em
C++. Portanto, nada a ver com Java.
Att.
--
Noelson
--
Você está recebendo e-mails da lista usuarios@pt-br.libreoffice.org
# Informações sobre os comandos disponíveis (em inglês):
mande e-mail vazio para usuarios+help@pt-br.**libreoffice.org<
usuarios%2Bhelp@pt-br.libreoffice.org>
# Cancelar sua assinatura: mande e-mail vazio para:
usuarios+unsubscribe@pt-br.**libreoffice.org<
usuarios%2Bunsubscribe@pt-br.libreoffice.org>
# Arquivo de mensagens: http://listarchives.**
libreoffice.org/pt-br/**
usuarios/ <http://listarchives.libreoffice.org/pt-br/usuarios/>
--
Você está recebendo e-mails da lista usuarios@pt-br.libreoffice.org
# Informações sobre os comandos disponíveis (em inglês):
mande e-mail vazio para usuarios+help@pt-br.libreoffice.org
# Cancelar sua assinatura: mande e-mail vazio para:
usuarios+unsubscribe@pt-br.libreoffice.org
# Arquivo de mensagens:
http://listarchives.libreoffice.org/pt-br/usuarios/
--
Você está recebendo e-mails da lista usuarios@pt-br.libreoffice.org
# Informações sobre os comandos disponíveis (em inglês):
mande e-mail vazio para usuarios+help@pt-br.libreoffice.org
# Cancelar sua assinatura: mande e-mail vazio para:
usuarios+unsubscribe@pt-br.libreoffice.org
# Arquivo de mensagens:
http://listarchives.libreoffice.org/pt-br/usuarios/
--
Você está recebendo e-mails da lista usuarios@pt-br.libreoffice.org
# Informações sobre os comandos disponíveis (em inglês):
mande e-mail vazio para usuarios+help@pt-br.libreoffice.org
# Cancelar sua assinatura: mande e-mail vazio para:
usuarios+unsubscribe@pt-br.libreoffice.org
# Arquivo de mensagens:
http://listarchives.libreoffice.org/pt-br/usuarios/
--
Você está recebendo e-mails da lista usuarios@pt-br.libreoffice.org
# Informações sobre os comandos disponíveis (em inglês):
mande e-mail vazio para usuarios+help@pt-br.libreoffice.org
# Cancelar sua assinatura: mande e-mail vazio para:
usuarios+unsubscribe@pt-br.libreoffice.org
# Arquivo de mensagens: http://listarchives.libreoffice.org/pt-br/usuarios/
Context
- Re: [pt-br-usuarios] [base] arquivo corrompido (continued)
- Re: [pt-br-usuarios] [base] arquivo corrompido · rogerio dandrea
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.