data restore using Backup data (1 Viewer)
- Thread starter Borror
- Start date
- Local time
- Today, 11:37
- Joined
- Feb 28, 2001
- Messages
- 27,338
A question or two might be in order before anyone answers that.
When you say "restore a database" there are many ways to do that but each has a different effect. Using a file picker implies you are doing a restoration from a specific file but from inside Access context. So what level of restoration are you asking about?
Are you going to pull data from old tables to new ones? Are you trying to replace an entire back-end file? What kind and level of restoration are you trying to do?
When you say "restore a database" there are many ways to do that but each has a different effect. Using a file picker implies you are doing a restoration from a specific file but from inside Access context. So what level of restoration are you asking about?
Are you going to pull data from old tables to new ones? Are you trying to replace an entire back-end file? What kind and level of restoration are you trying to do?
Please, Doc Man, the type of database restore I need is where a button is used to browse for a backup file from location and opened onto a path after that another button named restore is used to restore database. Please can you help?
I am trying to restore the entire database. That is, after a software is corrupted we use the backup file to restore on a blank Access database software. Total restoration, Doc Man.
Eagerly waiting for your reply.
Thanks, for caring.
I am trying to restore the entire database. That is, after a software is corrupted we use the backup file to restore on a blank Access database software. Total restoration, Doc Man.
Eagerly waiting for your reply.
Thanks, for caring.
Last edited:
- Local time
- Today, 11:37
- Joined
- Feb 28, 2001
- Messages
- 27,338
Here is your problem. If database A is suddenly corrupted, you will probably no longer be able to run it. Therefore, there would potentially be no viable infrastructure in which one could place a viable button such as you describe.
The file-picker dialog to browse a given folder and let you pick A-2018-07-01 or A-2018-07-08 or whatever other file you pick isn't the problem. It is where you could put this button such that it would still work that is the problem. Typically, corrupted databases stop working. Once that happens, NO buttons work.
Is this a shared or single-user database? If it is shared, I am also guessing here, but your question SOUNDS like you want your users to be able to do this. I believe this would be incredibly dangerous since in that case, it is the sort of thing that requires coordination among all users so that the "left hand knows what the right hand is doing." If TWO users attempted this at the same time and picked different backups to restore a shared database, chaos would follow closely.
Then, there is the question of whether this is a unified or split database. A split database has all data in a back-end (BE) file and everything else (queries, forms, reports, macros, modules) in a front-end (FE) file. A unified file is a single file that contains everything.
If the database is unified, you are dead in the water with having the database restore itself. It's like the old Warner Brothers cartoons where the character saws off the branch on where he is sitting and the rest of the tree falls down. You are in essence trying to replace the program you are actively using WHILE IT IS RUNNING. It is almost like you might imagine if a heart surgeon tried to transplant his own heart.
If the database is split, this potential update of the BE file (only) could occur, but only if you ALWAYS used late-linking on the FE so that it would come up "clean" and THEN be able to link to a given BE. No offense is intended, but given your description and the difficulty of setting up this kind of situation, I'm betting that you did not have this kind of set up. It would be beyond the skills of most beginners and even some mid-level developers.
Therefore, if you have a corrupted database, your better choice is to use WINDOWS (not Access) to just select and copy the file. Read through my answer to consider the factors. If you have further questions, please don't hesitate to ask.
The file-picker dialog to browse a given folder and let you pick A-2018-07-01 or A-2018-07-08 or whatever other file you pick isn't the problem. It is where you could put this button such that it would still work that is the problem. Typically, corrupted databases stop working. Once that happens, NO buttons work.
Is this a shared or single-user database? If it is shared, I am also guessing here, but your question SOUNDS like you want your users to be able to do this. I believe this would be incredibly dangerous since in that case, it is the sort of thing that requires coordination among all users so that the "left hand knows what the right hand is doing." If TWO users attempted this at the same time and picked different backups to restore a shared database, chaos would follow closely.
Then, there is the question of whether this is a unified or split database. A split database has all data in a back-end (BE) file and everything else (queries, forms, reports, macros, modules) in a front-end (FE) file. A unified file is a single file that contains everything.
If the database is unified, you are dead in the water with having the database restore itself. It's like the old Warner Brothers cartoons where the character saws off the branch on where he is sitting and the rest of the tree falls down. You are in essence trying to replace the program you are actively using WHILE IT IS RUNNING. It is almost like you might imagine if a heart surgeon tried to transplant his own heart.
If the database is split, this potential update of the BE file (only) could occur, but only if you ALWAYS used late-linking on the FE so that it would come up "clean" and THEN be able to link to a given BE. No offense is intended, but given your description and the difficulty of setting up this kind of situation, I'm betting that you did not have this kind of set up. It would be beyond the skills of most beginners and even some mid-level developers.
Therefore, if you have a corrupted database, your better choice is to use WINDOWS (not Access) to just select and copy the file. Read through my answer to consider the factors. If you have further questions, please don't hesitate to ask.
arnelgp
..forever waiting... waiting for jellybean!
- Local time
- Tomorrow, 00:37
- Joined
- May 7, 2009
- Messages
- 19,246
if the codes are still working, you can do the restore.
but there is a catch.
you need a 2nd tier db that will do the restoration (dbRestore).
these are the logic:
1. on orig db, open dbRestore.accdb.
2. maximize dbRestore (if minimized or small size).
3. close orig db.
4. from dbRestore, restore the oldbackup.
this is but a simple renaming of the orig db to some other name.
then renaming the backup db to the orig db name.
5. when dbRestore exits, it re-open the New DB.
its like a daisy chain.
extract the zip on same folder.
on the sample open Restorer.accdb first (you need to use Shift key while it is loading).
on vba, add reference to Microsoft Office Object (for the FileDialog).
close it.
open OrigDb (the demo form to use is Form1).
only tested in A2016 x64.
but there is a catch.
you need a 2nd tier db that will do the restoration (dbRestore).
these are the logic:
1. on orig db, open dbRestore.accdb.
2. maximize dbRestore (if minimized or small size).
3. close orig db.
4. from dbRestore, restore the oldbackup.
this is but a simple renaming of the orig db to some other name.
then renaming the backup db to the orig db name.
5. when dbRestore exits, it re-open the New DB.
its like a daisy chain.
extract the zip on same folder.
on the sample open Restorer.accdb first (you need to use Shift key while it is loading).
on vba, add reference to Microsoft Office Object (for the FileDialog).
close it.
open OrigDb (the demo form to use is Form1).
only tested in A2016 x64.
arnelgp
..forever waiting... waiting for jellybean!
- Local time
- Tomorrow, 00:37
- Joined
- May 7, 2009
- Messages
- 19,246
this is the i have so far.
this will copy all the access object from the backup.
it will ignore those object starting with "agp_" (since
the program uses this objects).
copy all "agp_<name>" to your database.
relink agp_tblBackUpDB back to restorer.accdb
restorer.accdb must reside on same folder
as your app database.
run agp_restore form to restore from backup.
only tested a couple of times.
this will copy all the access object from the backup.
it will ignore those object starting with "agp_" (since
the program uses this objects).
copy all "agp_<name>" to your database.
relink agp_tblBackUpDB back to restorer.accdb
restorer.accdb must reside on same folder
as your app database.
run agp_restore form to restore from backup.
only tested a couple of times.
