BAKUP AUTOMATICO COM ACCESS
pessoal preciso fazer um backup automático sem precisar abrir a caixa salvar, é que tenho o sistema no disco local C dentro da pasta SISTEMA e o banco de dados está logado em rede.
quero que faça um backup dentro da pasta SISTEMA quando sempre fechar o programa.
alguma ideia ai amigos.
quero que faça um backup dentro da pasta SISTEMA quando sempre fechar o programa.
alguma ideia ai amigos.
Simplesmente feche a conexão e copie o arquivo.
Backup com Access, problemas pela frente, todas as maquinas terão que estar com o sistema fechado no momento.
Backup automático, coisa praticamente impossÃvel,Ruim com banco de dados, pior com Access, o banco de dados ira tomando tamanho e ficaria cada vez mais demorado o bk, e como já disse teria que estar todas as maquinas com o sistema fechado.
Se for possÃvel, esqueça o Access e utilize um banco de dados.
Backup automático, coisa praticamente impossÃvel,Ruim com banco de dados, pior com Access, o banco de dados ira tomando tamanho e ficaria cada vez mais demorado o bk, e como já disse teria que estar todas as maquinas com o sistema fechado.
Se for possÃvel, esqueça o Access e utilize um banco de dados.
Você usa um acesso comum (em rede) ao arquivo, ok ? Independente da nomenclatura usada no mapeamento da pasta, o sistema operacional está utilizando um ponteiro para manter o acesso a esse arquivo.
Assim, para o caso do Access (e demais repositórios Flat File), o problema de backup não reside apenas no fato de ser necessário um acesso do tipo Exclusive - como indica a ADO - mas principalmente no próprio sistema operacional. Em outras palavras, esse ponteiro que o sistema usa para mapear o arquivo está dizendo que o arquivo está em uso, e isso pode bloquear a operação de cópia fÃsica, mesmo que se trate de uma cópia em baixo nÃvel.
Então, como já citado, é necessário que todas as conexões á esse arquivo sejam encerradas, em todas as estações. Ainda assim, o Windows em rede pode manter esse ponteiro sem atualização, indicando que o arquivo está em uso quando não está mais. Pode ocorrer por exemplo quando uma estação é desligada por queda de energia.
Se durante o backup você tem como objetivo também compactar a base de dados - shrink - o problema só aumenta, pois a única [Ô]via[Ô] é utilizar o procedimento do Jet Engine seja com a JRO, a DAO ou a ADO. O ideal nesse caso seria que a base de dados já fosse um MDE / ADE, que é o padrão do MS-Access para repositório auto-compactável, mas que tem o inconveniente de não permitir mais alterações nas estruturas de dados, relatórios, consultas e rotinas.
Como você aponta, sua ideia é que o backup seja feito ao final do trabalho, no encerramento da aplicação. Isso também pode se transformar em problema, pois justamente nesse momento, o usuário estará desligando a estação e não terá mais uma interface para acompanhar o andamento dessa cópia, que pode falhar ou demorar.
O procedimento de backup deveria ser um procedimento consciente, ou seja, efetuado com a opção clara do usuário. Mas isso parece não ser muito funcional para você, provavelmente por um motivo que todos conhecemos: Se deixar de fazer você mesmo, não será feito.
Dessa forma, apenas como sugestão - falando em termos da ADO - você pode criar os procedimentos para backup, e ao iniciar o aplicativo - e apenas se não detectar um arquivo de backup para a data em questão - conectar a base em modo exclusivo e efetuar esses procedimentos. Ao fazer isso, a primeira estação conectada no dia efetuará o backup, e as demais estações que tentem conectar-se durante esse processo, receberão a mensagem de que a base de dados não pode ser conectada, até que o procedimento tenha sido encerrado.
Nesse ponto, é bastante conveniente apontar que, como sugerido pelo KERPLUNK, efetuar a cópia fÃsica de um Flat File como o Access é bem mais rápido e eficiente do que utilizar um processo de backup nativo do MS-Access, e dessa forma, libera-se o arquivo de dados para conexão das estações mais rapidamente.
Assim, para o caso do Access (e demais repositórios Flat File), o problema de backup não reside apenas no fato de ser necessário um acesso do tipo Exclusive - como indica a ADO - mas principalmente no próprio sistema operacional. Em outras palavras, esse ponteiro que o sistema usa para mapear o arquivo está dizendo que o arquivo está em uso, e isso pode bloquear a operação de cópia fÃsica, mesmo que se trate de uma cópia em baixo nÃvel.
Então, como já citado, é necessário que todas as conexões á esse arquivo sejam encerradas, em todas as estações. Ainda assim, o Windows em rede pode manter esse ponteiro sem atualização, indicando que o arquivo está em uso quando não está mais. Pode ocorrer por exemplo quando uma estação é desligada por queda de energia.
Se durante o backup você tem como objetivo também compactar a base de dados - shrink - o problema só aumenta, pois a única [Ô]via[Ô] é utilizar o procedimento do Jet Engine seja com a JRO, a DAO ou a ADO. O ideal nesse caso seria que a base de dados já fosse um MDE / ADE, que é o padrão do MS-Access para repositório auto-compactável, mas que tem o inconveniente de não permitir mais alterações nas estruturas de dados, relatórios, consultas e rotinas.
Como você aponta, sua ideia é que o backup seja feito ao final do trabalho, no encerramento da aplicação. Isso também pode se transformar em problema, pois justamente nesse momento, o usuário estará desligando a estação e não terá mais uma interface para acompanhar o andamento dessa cópia, que pode falhar ou demorar.
O procedimento de backup deveria ser um procedimento consciente, ou seja, efetuado com a opção clara do usuário. Mas isso parece não ser muito funcional para você, provavelmente por um motivo que todos conhecemos: Se deixar de fazer você mesmo, não será feito.
Dessa forma, apenas como sugestão - falando em termos da ADO - você pode criar os procedimentos para backup, e ao iniciar o aplicativo - e apenas se não detectar um arquivo de backup para a data em questão - conectar a base em modo exclusivo e efetuar esses procedimentos. Ao fazer isso, a primeira estação conectada no dia efetuará o backup, e as demais estações que tentem conectar-se durante esse processo, receberão a mensagem de que a base de dados não pode ser conectada, até que o procedimento tenha sido encerrado.
Nesse ponto, é bastante conveniente apontar que, como sugerido pelo KERPLUNK, efetuar a cópia fÃsica de um Flat File como o Access é bem mais rápido e eficiente do que utilizar um processo de backup nativo do MS-Access, e dessa forma, libera-se o arquivo de dados para conexão das estações mais rapidamente.
Troca o access por um banco mais foda cara! SQL Server, MySQL, Oracle, PostgreSQL, MariaDB, Firebird! Nem precisa fazer outro banco do zero, é só usar algum programa de conversão. Eu achei um muito bom que converte access pra MySQL, é perfeito! E não se perde nenhum dado! Depois é só mudar algumas coisas na codificação do seu projeto. Agora se esta segunda ação vai dar mais trabalho ou não, vai depender em como está sua codificação. Eu mesmo posso migrar pra qualquer banco a qualquer momento já que sempre uso uma única classe pra conexão ao banco. Isso facilita muito nossa vida quando chega esses momentos cruciais. O problema do access é quando ultrapassa 1gb de tamanho, que pode se corromper a qualquer momento!
Eu particularmente prefiro o MySQL, por eles darem toda uma estrutura pro desenvolvedor. Uma coisa bacana é o MySQLBackup.DLL que você pode adicionar no seu projeto. Ele faz tanto backup quanto restore.
Boa sorte!
Eu particularmente prefiro o MySQL, por eles darem toda uma estrutura pro desenvolvedor. Uma coisa bacana é o MySQLBackup.DLL que você pode adicionar no seu projeto. Ele faz tanto backup quanto restore.
Boa sorte!
pessoal valeu pela dicas.
mas isso não meu ajudou no que estou procurando.
tudo o que preciso é saber se há como criar o backup sem precisar criar um processo de abrir a caixa de salvar como...
mas isso não meu ajudou no que estou procurando.
tudo o que preciso é saber se há como criar o backup sem precisar criar um processo de abrir a caixa de salvar como...
Eis um método pra backup
E eis um método pra restore
Como pode perceber está em c# mas não terás problema algum ao converter. Já que ambos trabalham em cima no .Net Framework. Quanto a sua idéia de gerar o backup toda vez que fechar a aplicação, é só pegar o seu formulário principal e incrementar tudo isso no evento FormClosing
Té mais
private void backupAccess()
{
string arquivo = [Ô]BKP[Ô] + DateTime.Now.Day.ToString() + [Ô]-[Ô] + DateTime.Now.Month.ToString() + [Ô]-[Ô] + DateTime.Now.Year.ToString();
if (MessageBox.Show([Ô]Está prestes a realizar um Backup do banco de dados. Confirma?[Ô], [Ô]Atenção[Ô], MessageBoxButtons.YesNo) == System.Windows.Forms.DialogResult.Yes)
{
if (System.IO.File.Exists(Application.StartupPath + @[Ô]\Banco\Backups\[Ô] + arquivo + [Ô].mdb[Ô]))
{
System.IO.File.Delete(Application.StartupPath + @[Ô]\Banco\Backups\[Ô] + arquivo + [Ô].mdb[Ô]);
}
System.IO.File.Copy(Application.StartupPath + @[Ô]\Banco\Banco.mdb[Ô], Application.StartupPath + @[Ô]\Banco\Backups\[Ô] + arquivo + [Ô].mdb[Ô]);
MessageBox.Show([Ô]Backup realizado com sucesso!
Nome do backup: [Ô] + arquivo);
}
}E eis um método pra restore
private void restoreAccess(){
OpenFileDialog open = new OpenFileDialog();
open.Filter = [Ô]Supported Files(*.mdb)|*.mdb[Ô];
open.InitialDirectory = Application.StartupPath + @[Ô]\Banco\Backups[Ô];
open.ShowDialog();
string arquivo = open.FileName;
if (MessageBox.Show([Ô]Está prestes a restaurar o Backup do banco de dados. Confirma?[Ô], [Ô]Atenção[Ô], MessageBoxButtons.YesNo) == System.Windows.Forms.DialogResult.Yes)
{
if (System.IO.File.Exists(Application.StartupPath + @[Ô]\Banco\Banco.mdb[Ô]))
{
System.IO.File.Delete(Application.StartupPath + @[Ô]\Banco\Banco.mdb[Ô]);
}
System.IO.File.Copy(arquivo, Application.StartupPath + @[Ô]\Banco\Banco.mdb[Ô]);
MessageBox.Show([Ô]Restauração de Backup realizada com sucesso![Ô]);
}
}Como pode perceber está em c# mas não terás problema algum ao converter. Já que ambos trabalham em cima no .Net Framework. Quanto a sua idéia de gerar o backup toda vez que fechar a aplicação, é só pegar o seu formulário principal e incrementar tudo isso no evento FormClosing
Té mais
galera onde estou falhando, não está gravando conforme o caminho que declarei
Private Sub backupAccess()
If System.IO.File.Exists([Ô]C:\Sistema\bdagenda.accdb[Ô]) Then
System.IO.File.Delete(Application.StartupPath + [Ô]C:\Sistema\bdagenda.accdb[Ô])
End If
System.IO.File.Copy(Application.StartupPath + [Ô]C:\Sistema\bdagenda.accdb[Ô], Application.StartupPath + [Ô]C:\Sistema\bdagenda.accdb[Ô])
End Sub
Amigo, veja bem, o que você acha que [Ô]Application.StartupPath[Ô] seja? Depure as linhas passo a passo e veja o que ela contém...
é isso mesmo KERPLUNK. Application.StartupPath serve justamente pra pegar o diretório onde o executável da aplicação se encontra. Ou seja não tem necessidade nenhuma de colocar todo o caminho fixo. Qual a vantagem disso? simplesmente quando for distribuir a aplicação para seus clientes não ter a obrigação de instalar na pasta c:\algumacoisa. Assim você pode instalar em qualquer lugar.
Crie uma pasta backup dentro da onde estiver, o .exe....
Private Sub backupAccess()
If System.IO.File.Exists(Application.StartupPath + [Ô]\backup\banco.accdb[Ô]) Then
System.IO.File.Delete(Application.StartupPath + [Ô]\backup\banco.accdb[Ô])
System.IO.File.Copy(Application.StartupPath + [Ô]\banco.accdb[Ô], Application.StartupPath + [Ô]\backup\banco.accdb[Ô])
End If
End Sub
Private Sub backupAccess()
If System.IO.File.Exists(Application.StartupPath + [Ô]\backup\banco.accdb[Ô]) Then
System.IO.File.Delete(Application.StartupPath + [Ô]\backup\banco.accdb[Ô])
System.IO.File.Copy(Application.StartupPath + [Ô]\banco.accdb[Ô], Application.StartupPath + [Ô]\backup\banco.accdb[Ô])
End If
End Sub
Tópico encerrado , respostas não são mais permitidas