| Autor |
Mensagem |
|
|
Desculpa Luca..achei que o tópico não tinha sido publicado porquê o tópico não estava aparecendo quando postei. 
|
 |
|
|
Estou usando o h2 e ele supriu o problema.
Vou testar também o Java DB em modo "Embedded Server". Posto o resultado aqui para informar...
|
|
|
|
O problema é que aqui eu não tenho a opção de usar Client/Server.
Acho que a opção "Embedded Server" daria certo aqui..preciso testar para ver.
Assim que eu testar, publico o resultado aqui neste tópico, para informar futuras pessoas com dúvidas sobre isso.
Mas acabei usando o h2 Database. Supriu as necessidades.
Obrigado!
|
|
|
|
Pessoal, boa tarde!
Estou com um banco de dados embedded (acessado pelo arquivo, sem servidor) salvo em um servidor de arquivos (infelizmente não tenho como usar servidor web, banco em modo de servidor ou outra solução do gênero, conforme descrito: http://www.guj.com.br/posts/list/138067.java)
O problema é que têm várias aplicações clientes que acessam esse banco e quando uma aplicação acessa o bd, as outras ficam bloqueadas para acesso ao mesmo.
Como posso contornar isso? Existe alguma configuração a fazer? Não estou querendo voltar a usar ACCESS por causa disso...até porquê a velocidade das consultas aumentou enormemente...
|
|
|
|
Estou com problemas para utilizar o JAVA DB. Estou usando em modo embedded um banco de dados hospedado em um servidor de arquivos (não temos disponível um servidor web - e qualquer sugestão nesse sentido está descartada infelizmente - vide tópico que já postei explicando a situação: http://www.guj.com.br/posts/list/138067.java#744568).
Tenho vários aplicativos clientes acessando o banco em rede. Mas o Java DB só está permitindo um usuário acessando o banco, por vez.
Como posso contornar o problema? Há alguma configuração para isso?
|
|
|
|
|
Ok. Vou tentar. Mas no momento, vou ter que testar um por um. Obrigado pela dica!
|
|
|
|
Colocar senha no ACCESS e acessar pelo Java é algo que eu nunca consegui..tentei de váááááriiiasss formas...
Coloquei as strings de conexão..configurei properties...nada...
Melhor voce encriptar as senhas mesmo...
|
|
|
|
Eu já acho o contrário... Mas nesse ponto você está certo: facilita a portabilidade para outro banco, sem dúvida.
Mas não creio nesse ponto de facilidade em programar...porquê vou ter que automatizar várias tarefas de gerenciamento e programar muito..muito mais do que se simplesmente concentrasse todas as tarefas em Stored Procedures e chamasse elas pelo aplicativo...
|
|
|
|
O JavaDB é um pouco pesado, mas ele tem uma vantagem que é o fato de permitir arquivos de dados criptografados. Pode ficar um pouco mais pesado, mas muitas aplicações precisam disso. (Imagine se alguém fica "fuçando" nos arquivos da aplicação e resolve editar alguns dados manualmente, como salários )
É, eu percebi na hora que fui fuçar nesses arquivos, para conhecer a estrutura. Isso é um grande ponto positivo!
Bom, fiz um pequeno programa com o JAVA DB. Rodou legal. Mas tive dificuldades para criar PROCEDURES, já que sabia criar com a linguagem do SQL Server (PL / Transact SQL), e nao consegui mesmo criá-las agora...
Vou considerar todas as sugestões...o que procuro mesmo é um banco que tenha bom desempenho, mesmo sendo baseado em arquivos, e que suporte quantidades muito grandes de registros. Além disso, ele será acessado em rede, mas em um servidor de arquivos (por isso têm que ser em "arquivo") - ou seja, terá que suportar bem concorrência.
Bom, obrigado pelas sugestoes. Vou tentar empregá-las em cada novo projeto.
|
|
|
|
Bom, comecei usando o JAVA DB..apanhei um pouco, mas consegui fazer uma conexão e extrair os dados de uma consulta.
Para um começo, está bom. Só estava relutante em usar o java db no início porquê encontrar material de referência (principalmente mais claros) e ferramentas, para auxilío no manuseio, é mais dificil que para outros SGBD'S mais utilizados.
Depois vou testar o HSQL. Pelo que vi na página dele, parece que cumpre minhas expectativas... e vou precisar de um SGBD mais prático para programas que empregarão grandes quantidades de registros.
Obrigado!
|
|
|
|
Ok..estou seguindo um tutorial de como utilizá-lo offline.
Obrigado!
Mas somente para esclarecimentos, teria como usar outros..como o mySQL por exemplo?
|
|
|
|
Boa tarde!
Alguém conhece um SGBD que eu possa empregar para substituir o MS ACCESS? Estou trabalhando com recursos que não podem mudar...e o que tenho disponível é um servidor de arquivos somente, no qual são efetuadas poucas mudanças e que não dependem de mim, e sim de um departamento de uma grande empresa que não disponibiliza no tempo suficiente o que precisamos.
Um exemplo: para disponibilizarem o SQL SERVER, estamos esperando há anos...
Desta forma, temos usado MS ACCESS. No começo, não havia grandes problemas. Mas com o passar do tempo, quando fomos criando sistemas mais complexos, que exigiam maior escalabilidade e controle de concorrências do banco, começaram a surgir inúmeros problemas, seja de gerenciamento do BD, como de integridade dos dados armazenados....
Gostaria de saber, então, para acabar com o problema, qual SGBD baseado em arquivo pode ser empregado. Um SGBD que não dependa de servidor e que possa ser acessado em rede (como um arquivo .mdb em rede, como fazemos atualmente no caso do ACCESS).
Não precisa ser um SGBD só baseado em arquivos... pode ser um SGBD conceituado que funcione das duas formas (assim, uma futura migração ficaria mais simples...)
|
|
|
|
Pessoal..descobri qual a solução desse problema... e o pior, é muito fácil de resolver..
Mas o problema é que é algo difícil de você perceber que seria a causa de tantos problemas...:
Vou postar aqui para todos que tiverem o mesmo problema, saberem onde procurar.
Esse erro se dá devido ao driver odbc que você especifica quando cria a conexão:
Dependendo do driver, ele não dá suporte para ResultSets atualizáveis e daí ocasiona o erro. No caso, eu estava usando o DriverID=22 do qual não fazia nem idéia que era um driver vagabundo que não dava suporte pra nada... (eheheeh). Pesquisei na internet por dias e não achei nada que indicasse que o indômito driver era o grande culpado!
Só foi tirar esse troço da string de conexão e pronto..já posso atualizar!
Muito obrigado e fica aqui a solução. Caso aconteça esse erro, cheque:
- a string de conexão e O FAMIGERADO DRIVER ID;
- se você está atualizando um campo de um tipo, com método update de outro tipo. Por exemplo, rs.updateString para campos que no bd são tipos numéricos;
- se o seu bd do access está corrompido.
|
|
|
|
Posso utilizar resultsets para atualizar registros de um banco em ACCESS?
Estou colocando o código abaixo para exemplificar o que estou tentando fazer:
O motivo de usar este método é que estou manipulando um array de objetos e para alguns objetos podem haver alterações no banco e para outros não.
Por isso achei que era melhor usar um resultset para, nos registros que eu realmente precisar atualizar, usar o resultset para isso.
Quando eu rodo meu código, que é bem maior que o exemplo acima, ocorre o seguinte erro (na linha onde eu dou o rs.updateRow() :
|
|
|
|
Gostaria de saber se têm como incluir várias consultas a STORED PROCEDURES diferentes em BATCH dentro de um CallableStatement??
Quando tento desta forma, só adiciona o último sql que foi incluído no batch:
Tentei de outra forma, mas dá erro:
Ressaltando que em ambas as instruções estou configurando os parâmetros corretamente (apenas omiti estes trechos).
Grato desde já!
|
|
|
|
|
|