REPARAR BANCO DE DADOS - ACCESS
Caros !
Tenho problemas com o banco de dados ACCESS quando a queda de energia ou o sistema é fechado inesperadamente, o famoso [Ô] BANCO DE DADOS CORROMPIDO [Ô], tem algum programa automático e de simples o uso para que o próprio usuário possa executar e sanar o problema? ou até um programa em Visual Basic que possa estar desenvolvendo para corrigir o mesmo.
Atualmente eu abro o banco pelo ACCESS e o mesmo repara, solucionando o problema.
Tenho problemas com o banco de dados ACCESS quando a queda de energia ou o sistema é fechado inesperadamente, o famoso [Ô] BANCO DE DADOS CORROMPIDO [Ô], tem algum programa automático e de simples o uso para que o próprio usuário possa executar e sanar o problema? ou até um programa em Visual Basic que possa estar desenvolvendo para corrigir o mesmo.
Atualmente eu abro o banco pelo ACCESS e o mesmo repara, solucionando o problema.
Qual a versão do Access que está usando?
Tente usar uma base de dados nova com a mesma estrutura do arquivo .mdb danificado para importar os registros e veja se vai.
Qualquer coisa, tente corrigir o seu problema aqui:
https://online.officerecovery.com/pt/access/
https://online.officerecovery.com/pt/access/
No Visual Basic meu data está como Conect Access 2000
Citação:Tenho problemas com o banco de dados ACCESS quando a queda de energia ou o sistema é fechado inesperadamente, o famoso [Ô] BANCO DE DADOS CORROMPIDO [Ô], tem algum programa automático e de simples o uso para que o próprio usuário possa executar e sanar o problema? ou até um programa em Visual Basic que possa estar desenvolvendo para corrigir o mesmo.
Atualmente eu abro o banco pelo ACCESS e o mesmo repara, solucionando o problema.
Acredito que você está querendo saber se há como efetuar o reparo por meio de código. Se você utiliza DAO, há um método, se utiliza ADO, há outra forma.
DAO:
RepairDatabase [Ô]C:\banco.mdb[Ô]
CompactDatabase [Ô]C:\banco.mdb[Ô], App.Path & [Ô]\copia.mdb[Ô]ADO: Neste caso, você precisa referenciar a Jet and Replication Objects
Dim JRO As New JRO.JetEngine
JRO.CompactDatabase [Ô]Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\banco.mdb[Ô], [Ô]Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\copia.mdb;Jet OLEDB:Engine Type=4[Ô]Sobre o problema em sÃ, ele ocorre quando há uma [Ô]quebra[Ô] não-tratada do aplicativo (que é o seu caso), mas também ocorre quando algum ponto de rede perde conexão durante alguma operação CRUD. E esse é um dos problemas do MS-Access. O outro é o fato de que o Jet Engine não é um Client/Server, e acaba por sobrecarregar o tráfego de rede e a memória da estação, invariavelmente. Ainda assim, é um excelente banco de dados, desde que o programador/desenvolvedor não esqueça de [Ô]cuidar bem[Ô] das conexões.
Tenho lido aqui muita gente defender que [Ô]o ideal é conectar á base quando inicia o aplicativo e só desconectar ao encerrar o aplicativo[Ô] (i.e. conexão perene, ou seja, aquela que sempre está aberta), baseando-se no fato de que isso melhora a performance.
De fato, não ter conectar várias vezes, quando a string de conexão não utiliza a cláusula [Ô]Persist Security Info=True[Ô], oferece melhor desempenho, mas também acarreta mais problemas de estabilidade fÃsica para o banco de dados. é uma escolha que se deve fazer, entre estabilidade e desempenho.
Pessoalmente, se eu preciso desempenho, escolho uma base Client/Server, como o SQL Server ou o MySQL. Quando é uma aplicação de suporte, algo menor, crio rotinas genéricas para as operações CRUD, sendo que á cada operação a conexão se abre e se encerra, mantenho as informações de segurança e evito ao máximo o uso de grades e consultas sem filtragem, assim como a carga de tabelas cheias (como [Ô]SELECT * FROM[Ô] ou oRecordset.Open([Ô]MinhaTabela[Ô])). O desempenho é um pouco menor, mas com isso, o problema de [Ô]Unrecognized Database Format[Ô] praticamente deixa de existir. No meu modo de ver, apenas quando e se os usuários reclamam de desempenho, então se deve pensar em mudar o mecanismo de armazenamento de dados, e não em acelerar o aplicativo usando conexões perenes, que é o mesmo que [Ô]turbinar[Ô] um motor de fusca: Funciona, mas todos sabem que aumenta em muito o risco de em algum momento, estourar, e quando isso acontece, não há garantias para cobrir o prejuizo.
Citação:Tenho lido aqui muita gente defender que [Ô]o ideal é conectar á base quando inicia o aplicativo e só desconectar ao encerrar o aplicativo[Ô] (i.e. conexão perene, ou seja, aquela que sempre está aberta), baseando-se no fato de que isso melhora a performance.
De fato, não ter conectar várias vezes, quando a string de conexão não utiliza a cláusula [Ô]Persist Security Info=True[Ô], oferece melhor desempenho, mas também acarreta mais problemas de estabilidade fÃsica para o banco de dados. é uma escolha que se deve fazer, entre estabilidade e desempenho.
VIVA OS BACKUPS
bom colega se for uma aplicação local de um unico usuario, abra e feche a conexao a cada consulta
MARCELO-TREZE
Sempre que leio seus posts, suas respostas, concordo com 99% das suas inferências, pois sei por experiência que estão certas. Apenas neste caso, de manter conexões perenes, é que discordo, e antes de mais nada devo deixar claro que mesmo discordando, não critico nem condeno a sua posição, de forma alguma. Assim sendo, peço desculpas caso você tenha se sentido incomodado com algo que eu tenha escrito ou com algum modo de me expressar.
E veja, com a mais absoluta certeza, nada tem á ver a quantidade de usuários de minha aplicação com a minha opção de forma de conexão, até porquê o usuário do serviço de dados, seja no MS-Access ou no SQL Server, é sempre apenas um e o mesmo. Claro que, se implemento uma integração do SQL Server ao Active Directory e á aplicação, a quantidade de usuários passa á ter algum significado, até porquê o texto de conexão se altera em cada sessão, mas ainda assim, nada que influencie a performance de forma desastrosa, como você teme que possa ocorrer.
Só para dar uma idéia, a MSC do Brasil, que é a terceira maior empresa de transportes marÃtimos no mundo, utilizou-se por muitos anos de uma mesma base de dados MS-Access 97, com bem mais de 300 usuários simultâneos em diversas cidades (São Paulo, Santos, Vitória, Rio de Janeiro e Santiago/Chile), usando apenas um conjunto de roitinas CRUD genéricas, que se conectavam á base apenas no momento de executar as operações e durante a execução das mesmas. Foi feita uma migração para SQL Server, sim, e ocorreu no momento em que a base MS-Access estava com um tamanho de 2.5Gbytes compactada, quando as recomendações da Microsoft eram as de não mais usar esse mecanismo caso o volume chegasse á 2Gb, ou seja usamos até além dos limites, sem a ocorrência de problemas nem queixas de performance.
Minto: Ocorreram corrupções de arquivo em duas ocasiões, ambas motivadas por queda de energia na filial aqui de Santos, onde ficava o servidor com o MS-Access. Em ambas as vezes, os geradores não foram rápidos o suficiente, mas logo depois a empresa se muniu de dois NoBreaks de alta capacidade e o fato nunca mais se repetiu.
Claro, veja, eu nunca usei um SELECT *, por exemplo, também não usava DataControls e não deixava aos encargos de um Crystal Reports as tarefas de se conectar automaticamente á base de dados ou de interpretar um select composto.
Mas só para fins de defender a minha posição, independente da minha experiência, acompanhe comigo:
Até a DAO, aplicações com dados na Web eram mais difÃceis de se criar. O apelo era a ODBC e as diferenças nos mecanismos de dados eram mais acentuadas, os drivers eram poucos etc.
Com a ADO (ADODB), esse tipo de aplicação (Web) passou á ser bem mais simples de se desenvolver. No entanto, uma conexão á dados em uma aplicação Web (usando, portanto, o IIS) não se mantém ativa: Ela encerra [Ô]sozinha[Ô] após um TimeOut, mesmo quando o programador não lembra de chamar o método Close. Não lembro de ter visto, nem ouvido falar, nessa época nenhuma aplicação Web usando ADO com conexões perenes, e ainda assim, eram aplicações acessadas por centenas, ás vezes milhares de usuários.
Conforme o tempo foi passando, a tecnologia foi se aprimorando, e surgiu a ADO.Net (2002). A ADO.Net não é apenas uma adaptação da ADODB, mas sim todo um conjunto de ferramentas totalmente novas, visando o trabalho com bancos de dados desconectados, ou seja, você ordena, filtra, altera, inclui, edita, filtra e seleciona, á vontade, á partir de uma coleção, mesmo estando desconectado da base de dados, e depois de estar bem certo das operações que realizou, só então conecta-se novamente para efetivar (ou refletir) as mudanças no serviço de dados.
Bom, se você criar duas versões da mesma aplicação, uma usando a ADODB e outra a ADO.Net, e ambas com um volume de dados razoável, vai perceber claramente que a ADODB é mais rápida que a ADO.Net. Nem por isso, no entanto, a Microsoft abriu mão de [Ô]aposentar[Ô] a ADODB (ela é mantida hoje apenas para compatibilidade e aplicações herdadas) e continuar evoluindo a ADO.Net.
Infelizmente não posso confirmar, mas segundo alguns rumores, o próprio MS-Access vai deixar de usar a DAO, e pode ser até que deixe de existir como mecanismo de dados, sendo substituÃdo por uma IDE similar à quelas geradas pelo Lightswitch, com o mecanismo SQL Server CE ou derivado. Isso pode não parecer grande coisa, mas caso se confirme, é mais um passo á favor das conexões pontuais.
Com TUDO ISSO, só o que eu estou dizendo é que a minha preferência pessoal, é por lidar com conexões pontuais em favor as conexões perenes. Isso não quer dizer que eu estou afirmando que você esta errado, ou que deva trabalhar de forma diferente, ao contrário, é sempre muito bom ter opiniões diferentes, onde ambos os lados conseguem atingir os objetivos igualmente, pois o conjunto resultante disso é uma somatória de experiências positivas, que pode ser utilizado depois por quaisquer outras pessoas.
Azul ou amarelo, não importa uma ou outra, mas sim saber que ambas são opções na mesma paleta, que podemos escolher quando for necessário.
Destaco, só para encerrar, que em têrmos de performance, a sua posição é de fato melhor, não tenho dúvidas. Ainda assim, vejo a minha posição garantindo maior segurança á integridade fÃsica de bases de dados de arquivo, como o MS-Access.
E novamente me desculpo por qualquer coisa que eu possa ter escrito que o tenha ofendido/irritado. Se o fiz, foi sem o intuito, e ainda não sei o que possa ter sido.
Sempre que leio seus posts, suas respostas, concordo com 99% das suas inferências, pois sei por experiência que estão certas. Apenas neste caso, de manter conexões perenes, é que discordo, e antes de mais nada devo deixar claro que mesmo discordando, não critico nem condeno a sua posição, de forma alguma. Assim sendo, peço desculpas caso você tenha se sentido incomodado com algo que eu tenha escrito ou com algum modo de me expressar.
E veja, com a mais absoluta certeza, nada tem á ver a quantidade de usuários de minha aplicação com a minha opção de forma de conexão, até porquê o usuário do serviço de dados, seja no MS-Access ou no SQL Server, é sempre apenas um e o mesmo. Claro que, se implemento uma integração do SQL Server ao Active Directory e á aplicação, a quantidade de usuários passa á ter algum significado, até porquê o texto de conexão se altera em cada sessão, mas ainda assim, nada que influencie a performance de forma desastrosa, como você teme que possa ocorrer.
Só para dar uma idéia, a MSC do Brasil, que é a terceira maior empresa de transportes marÃtimos no mundo, utilizou-se por muitos anos de uma mesma base de dados MS-Access 97, com bem mais de 300 usuários simultâneos em diversas cidades (São Paulo, Santos, Vitória, Rio de Janeiro e Santiago/Chile), usando apenas um conjunto de roitinas CRUD genéricas, que se conectavam á base apenas no momento de executar as operações e durante a execução das mesmas. Foi feita uma migração para SQL Server, sim, e ocorreu no momento em que a base MS-Access estava com um tamanho de 2.5Gbytes compactada, quando as recomendações da Microsoft eram as de não mais usar esse mecanismo caso o volume chegasse á 2Gb, ou seja usamos até além dos limites, sem a ocorrência de problemas nem queixas de performance.
Minto: Ocorreram corrupções de arquivo em duas ocasiões, ambas motivadas por queda de energia na filial aqui de Santos, onde ficava o servidor com o MS-Access. Em ambas as vezes, os geradores não foram rápidos o suficiente, mas logo depois a empresa se muniu de dois NoBreaks de alta capacidade e o fato nunca mais se repetiu.
Claro, veja, eu nunca usei um SELECT *, por exemplo, também não usava DataControls e não deixava aos encargos de um Crystal Reports as tarefas de se conectar automaticamente á base de dados ou de interpretar um select composto.
Mas só para fins de defender a minha posição, independente da minha experiência, acompanhe comigo:
Até a DAO, aplicações com dados na Web eram mais difÃceis de se criar. O apelo era a ODBC e as diferenças nos mecanismos de dados eram mais acentuadas, os drivers eram poucos etc.
Com a ADO (ADODB), esse tipo de aplicação (Web) passou á ser bem mais simples de se desenvolver. No entanto, uma conexão á dados em uma aplicação Web (usando, portanto, o IIS) não se mantém ativa: Ela encerra [Ô]sozinha[Ô] após um TimeOut, mesmo quando o programador não lembra de chamar o método Close. Não lembro de ter visto, nem ouvido falar, nessa época nenhuma aplicação Web usando ADO com conexões perenes, e ainda assim, eram aplicações acessadas por centenas, ás vezes milhares de usuários.
Conforme o tempo foi passando, a tecnologia foi se aprimorando, e surgiu a ADO.Net (2002). A ADO.Net não é apenas uma adaptação da ADODB, mas sim todo um conjunto de ferramentas totalmente novas, visando o trabalho com bancos de dados desconectados, ou seja, você ordena, filtra, altera, inclui, edita, filtra e seleciona, á vontade, á partir de uma coleção, mesmo estando desconectado da base de dados, e depois de estar bem certo das operações que realizou, só então conecta-se novamente para efetivar (ou refletir) as mudanças no serviço de dados.
Bom, se você criar duas versões da mesma aplicação, uma usando a ADODB e outra a ADO.Net, e ambas com um volume de dados razoável, vai perceber claramente que a ADODB é mais rápida que a ADO.Net. Nem por isso, no entanto, a Microsoft abriu mão de [Ô]aposentar[Ô] a ADODB (ela é mantida hoje apenas para compatibilidade e aplicações herdadas) e continuar evoluindo a ADO.Net.
Infelizmente não posso confirmar, mas segundo alguns rumores, o próprio MS-Access vai deixar de usar a DAO, e pode ser até que deixe de existir como mecanismo de dados, sendo substituÃdo por uma IDE similar à quelas geradas pelo Lightswitch, com o mecanismo SQL Server CE ou derivado. Isso pode não parecer grande coisa, mas caso se confirme, é mais um passo á favor das conexões pontuais.
Com TUDO ISSO, só o que eu estou dizendo é que a minha preferência pessoal, é por lidar com conexões pontuais em favor as conexões perenes. Isso não quer dizer que eu estou afirmando que você esta errado, ou que deva trabalhar de forma diferente, ao contrário, é sempre muito bom ter opiniões diferentes, onde ambos os lados conseguem atingir os objetivos igualmente, pois o conjunto resultante disso é uma somatória de experiências positivas, que pode ser utilizado depois por quaisquer outras pessoas.
Azul ou amarelo, não importa uma ou outra, mas sim saber que ambas são opções na mesma paleta, que podemos escolher quando for necessário.
Destaco, só para encerrar, que em têrmos de performance, a sua posição é de fato melhor, não tenho dúvidas. Ainda assim, vejo a minha posição garantindo maior segurança á integridade fÃsica de bases de dados de arquivo, como o MS-Access.
E novamente me desculpo por qualquer coisa que eu possa ter escrito que o tenha ofendido/irritado. Se o fiz, foi sem o intuito, e ainda não sei o que possa ter sido.
Fuja do Access o mais rapido possivel, e o proprio Access já faz isso, que eu saiba pelo menos do 2007 para frente já me reparou uns 100 corrompido, tudo por queda de energia ou rede. Não da trabalho nenhum, nem compensa perder tempo criando códigos. Minha opinião, é claro.
Por isso estou migrando aos poucos, ainda faltam 50 clientes passarem para Mysql.
Por isso estou migrando aos poucos, ainda faltam 50 clientes passarem para Mysql.
Olá amigos !
Meu problema está 90% em queda de energia sim, concordo também que a melhor solução é sim passar para MySQL, só que isso leva um tempo, e de imediato procuro uma solução. Sei também que a maneira mais fácil é abrir o banco pelo próprio ACCESS que o mesmo já repara, isso para mim é fácil, difÃcil é ter que ficar acessando clientes ou explicando para usuários como fazer isso, até porque tenho vários clientes 24 horas.
PROFESSOR
DAO:
RepairDatabase [Ô]C:\banco.mdb[Ô]
CompactDatabase [Ô]C:\banco.mdb[Ô], App.Path & [Ô]\copia.mdb[Ô]
Neste, qual é a referência necessária para que eu possa estar testando pois dá função RepairDatabase não definida
ADO: Neste caso, você precisa referenciar a Jet and Replication Objects
Dim JRO As New JRO.JetEngine
JRO.CompactDatabase [Ô]Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\banco.mdb[Ô], [Ô]Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\copia.mdb;Jet OLEDB:Engine Type=4[Ô]
Neste o mesmo dá que Formato do Banco de Dados inválido.
Meu problema está 90% em queda de energia sim, concordo também que a melhor solução é sim passar para MySQL, só que isso leva um tempo, e de imediato procuro uma solução. Sei também que a maneira mais fácil é abrir o banco pelo próprio ACCESS que o mesmo já repara, isso para mim é fácil, difÃcil é ter que ficar acessando clientes ou explicando para usuários como fazer isso, até porque tenho vários clientes 24 horas.
PROFESSOR
DAO:
RepairDatabase [Ô]C:\banco.mdb[Ô]
CompactDatabase [Ô]C:\banco.mdb[Ô], App.Path & [Ô]\copia.mdb[Ô]
Neste, qual é a referência necessária para que eu possa estar testando pois dá função RepairDatabase não definida
ADO: Neste caso, você precisa referenciar a Jet and Replication Objects
Dim JRO As New JRO.JetEngine
JRO.CompactDatabase [Ô]Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\banco.mdb[Ô], [Ô]Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\copia.mdb;Jet OLEDB:Engine Type=4[Ô]
Neste o mesmo dá que Formato do Banco de Dados inválido.
PROFESSOR
Eu concordo plenamente com suas observações, e desculpe se pareci rude, costumo sempre ler seus post's e admiro a facilidade que você tem pra se fazer entender, didática incrÃvel, rs coisa de professor mesmo.
bom assim, a forma acima colocada é corretÃssima, nem discuto isso, porém você sabe tanto quanto eu que a primeira coisa que o cliente repara é no desempenho, e depois ao se habituar com o sistema começa a reparar na estabilidade, e quando coloquei o [Ô]VIVA OS BACKUPS[Ô], eu na verde quis dizer que a solução que encontrei foi esta manter o desempenho e aperfeiçoar os backups, apesar de não ter tido nenhum problema até agora.
Bom não vou prolongar muito, um bom sistema multiusuário depende de vários fatores, mas vários mesmo, no meu caso trabalho muito com procedures, uso as formas corretas de select também evito o *, o servidor, (que eu mesmo montei por possuir ip fixo) também segue algumas regras, no meu caso montei o servidor usando o sistema operacional linux ubunto (LAMP) lógico um nobreak, e até o momento não tive problemas, outra preocupação que tive foi criar um log de erros bem discriminado com objetivo de descobrir quando e como o usuário final causa o erro para poder fazer as melhorias no sistema, efim existe mais algumas coisinhas que tive de fazer.
Enfim eu gosto deste fórum por conta destas discussões, que só agregam conhecimentos aos menos experientes, de forma civilizada e humilde construÃmos uma comunidade virtual muito melhor, e mais uma vez reitero meus distintos votos de consideração e apreço pelo sr. Professor.
Citação:Com TUDO ISSO, só o que eu estou dizendo é que a minha preferência pessoal, é por lidar com conexões pontuais em favor as conexões perenes. Isso não quer dizer que eu estou afirmando que você esta errado, ou que deva trabalhar de forma diferente, ao contrário, é sempre muito bom ter opiniões diferentes, onde ambos os lados conseguem atingir os objetivos igualmente, pois o conjunto resultante disso é uma somatória de experiências positivas, que pode ser utilizado depois por quaisquer outras pessoas.
Eu concordo plenamente com suas observações, e desculpe se pareci rude, costumo sempre ler seus post's e admiro a facilidade que você tem pra se fazer entender, didática incrÃvel, rs coisa de professor mesmo.
bom assim, a forma acima colocada é corretÃssima, nem discuto isso, porém você sabe tanto quanto eu que a primeira coisa que o cliente repara é no desempenho, e depois ao se habituar com o sistema começa a reparar na estabilidade, e quando coloquei o [Ô]VIVA OS BACKUPS[Ô], eu na verde quis dizer que a solução que encontrei foi esta manter o desempenho e aperfeiçoar os backups, apesar de não ter tido nenhum problema até agora.
Bom não vou prolongar muito, um bom sistema multiusuário depende de vários fatores, mas vários mesmo, no meu caso trabalho muito com procedures, uso as formas corretas de select também evito o *, o servidor, (que eu mesmo montei por possuir ip fixo) também segue algumas regras, no meu caso montei o servidor usando o sistema operacional linux ubunto (LAMP) lógico um nobreak, e até o momento não tive problemas, outra preocupação que tive foi criar um log de erros bem discriminado com objetivo de descobrir quando e como o usuário final causa o erro para poder fazer as melhorias no sistema, efim existe mais algumas coisinhas que tive de fazer.
Enfim eu gosto deste fórum por conta destas discussões, que só agregam conhecimentos aos menos experientes, de forma civilizada e humilde construÃmos uma comunidade virtual muito melhor, e mais uma vez reitero meus distintos votos de consideração e apreço pelo sr. Professor.
Tópico encerrado , respostas não são mais permitidas