Backing up a secured database

[Guest]

I created a database for someone and secured it giving myself admin
permission and the person I created it for user permission. This database
currently resides on a thumbdrive. I would like this individual to have the
ability to back it up to his hard drive so that he has a second copy incase
he looses his thumbdrive. Would this be accomplished with a button on a form
and a macro? He is the only user.

 

[Pieter Wijnen]

*dirty* copying is not easy using DOS and/or Windows
better set up a scheduled task/desktop icon to copy the file

--
Pieter Wijnen

My feeble Access pages (good links though)
http://www.thuleeng.com/access
When all else fail try:
http://www.mvps.org/access
http://www.granite.ab.ca/
http://allenbrowne.com/
http://www.lebans.com/

 

[Guest]

So, it is not possible to back up a secured database to another location?
The only information on backing up a database that I have found is for
unsecured databases or those that have been split and are backed up on a
server. This is a private application, not a business, so there is no
server. Was this type of use not considered by MS?

 

[Rick Brandt]

So, it is not possible to back up a secured database to another
location? The only information on backing up a database that I have
found is for unsecured databases or those that have been split and
are backed up on a server. This is a private application, not a
business, so there is no server. Was this type of use not considered
by MS?

Of course it is possible. It is just not so easy to reliably do so from
within the very file you are trying to back up.

If you provide a menu option for doing the backup and that backup routine
first makes sure that all forms, reports and anything else that might be
accesssing data is first closed, then shelling to a DOS Copy command would
"probably" give you a good backup.

Is this user so computer illiterate that he is incapable of copying a file
on the thumb drive to his hard drive himself?

 

[Guest]

He is moderately computer literate, but that is not the issue. He wants to
sell this database to others who could use this application and I don't want
to be left out. The security is for me.

 

[Rick Brandt]

He is moderately computer literate, but that is not the issue. He
wants to sell this database to others who could use this application
and I don't want to be left out. The security is for me.

I fail to see what that has to do with his ability to make a copy. Anyone who
knows how to copy files will be able to copy your MDB and MDW to another system
and if they are provided with logon credentials for an appropriate user account
will be able to run the app.

 

[Guest]

Rick, I must be missing something. I have secured the database and removed
toolbars. There is no way to save from within the database. I haven't had
him try a drag and drop yet since there are peripheral files for the
security that need to go along. When securing it, the wizard sets up a
shortcut on the desktop. I tried to move that shortcut from my desktop to
the thumbdrive and found that all of the paths to these files had to be
changed. It got ugly. What I would like to do is put a button on the main
menu (switchboard) that he could press to backup to his desktop on the
laptop.

Maybe I am being overly security conscious. I have a 17-year old that has
managed to "blow-up" his computer a couple of times. If this database is on
a thumbdrive and a laptop; both are portable and can be damaged or lost;
hopefully not at the same time. If I install it on the laptop only, because
of the security files, then all it takes is a virus to wipe it out. All I
have stashed is the original program and none of the files he would loose. On
the other hand, if I don't secure the database, this enthusiastic individual
would share it and someone Access-literate could go in and make it their own.

There has to be a way to backup a secure database. If this were a business
with a server, the server is backed up. Can't that be done for a private
computer?

Yes, I hear you that other people could copy it secured and use it if the
password was given away. There is a certain amount of customization that
they wouldn't be able to get around.

 

[Rick Brandt]

Rick, I must be missing something. I have secured the database and
removed toolbars. There is no way to save from within the database.

Yes there is no way built into Access to make a copy of the database
currenlty opened. I have been assuming that YOU were creating a custom code
or macro that would do this.

I haven't had him try a drag and drop yet since there are peripheral
files for the security that need to go along. When securing it, the
wizard sets up a shortcut on the desktop. I tried to move that
shortcut from my desktop to the thumbdrive and found that all of the
paths to these files had to be changed. It got ugly. What I would
like to do is put a button on the main menu (switchboard) that he
could press to backup to his desktop on the laptop.

Maybe I am being overly security conscious. I have a 17-year old
that has managed to "blow-up" his computer a couple of times. If
this database is on a thumbdrive and a laptop; both are portable and
can be damaged or lost; hopefully not at the same time. If I install
it on the laptop only, because of the security files, then all it
takes is a virus to wipe it out. All I have stashed is the original
program and none of the files he would loose. On the other hand, if I
don't secure the database, this enthusiastic individual would share
it and someone Access-literate could go in and make it their own.

There has to be a way to backup a secure database. If this were a
business with a server, the server is backed up. Can't that be done
for a private computer?

Yes, both would be acomplished with backup software. Does your user have
backup software that he is using? If so all he has to do is have it include
the thumb-drive as one of the drives to back up.

 

[aaron.kempf]

Access MDB isn't an enterprise - level database.

use Access Data Projects; lose the training wheels.. Access MDB is for
newbies.

-Aaron

 

[Guest]

Yes there is no way built into Access to make a copy of the database
currenlty opened. I have been assuming that YOU were creating a custom code
or macro that would do this.

This is why I am querying this august venue. I don't know how to do this.
Please be so good as to advise how this is done.

Yes, both would be acomplished with backup software. Does your user have
backup software that he is using? If so all he has to do is have it include
the thumb-drive as one of the drives to back up.

This sounds good. Is backup software a brand or type? Do I just walk into
a computer place and ask for backup software? I suppose there are 31 flavors
of this as well. Any suggestions?

 

[Granny Spitz via AccessMonster.com]

I tried to move that shortcut from my desktop to
the thumbdrive and found that all of the paths to these files had to be
changed. It got ugly.

Please pardon my butting in, but I'd suggest burning the files to CD as a
backup of the original application. To restore these, he'd need to copy them
from the CD to his hard drive (or thumb drive), and then do two things: 1)
change the desktop shortcut target and 2) relink the tables on the back end,
if there is one. The shortcut target is like this (which is all one line):

"PathToOffice\MSAccess.exe" "PathToDB\DB.mdb" /wrkgrp "PathToMDW\Secure.mdw"

To relink the tables automatically, you can create a button on a form and the
code it would execute can be found here:
http://www.mvps.org/access/tables/tbl0009.htm

If I install it on the laptop only, because
of the security files, then all it takes is a virus to wipe it out.

If I'm reading this right, it sounds as if you believe that a virus would
target *just* the security files, and I'm guessing that's the workgroup file,
the MDW file, right? I don't believe there are any viruses that target just
MDW files. But maybe you mean the hard drive could be infected, so the data
on the whole hard drive would need to be replaced from backup, which would
wipe out all existing files.

On
the other hand, if I don't secure the database, this enthusiastic individual
would share it and someone Access-literate could go in and make it their own.

If you think Access User-level security is going to protect your database
from piracy, you are mistaken. Access security is easily broken by free
tools available on the web. People can open your database and make all the
changes they want.

other people could copy it secured and use it if the
password was given away. There is a certain amount of customization that
they wouldn't be able to get around.

They don't need a password if they have both the database file and the
workgroup file. If your application can be installed on one computer, then
it's unlikely that any customization you put in there will *prevent* it from
being installed successfully on another computer by someone who is determined.
What type of customization are you talking about? Hidden registry keys? A
password? The company name on forms and reports? These aren't difficult to
overcome, even with a secured database. If your compacted and zipped file
isn't large (< 5 MB), then you could send me the DB and MDW files, and I'd be
happy to show you the vulnerabilities.

 

[Rick Brandt]

This is why I am querying this august venue. I don't know how to do
this. Please be so good as to advise how this is done.


This sounds good. Is backup software a brand or type? Do I just
walk into a computer place and ask for backup software? I suppose
there are 31 flavors of this as well. Any suggestions?

 

[Guest]

Please pardon my butting in, but I'd suggest burning the files to CD as a
backup of the original application. To restore these, he'd need to copy them
from the CD to his hard drive (or thumb drive), and then do two things: 1)
change the desktop shortcut target and 2) relink the tables on the back end,
if there is one. The shortcut target is like this (which is all one line):

"PathToOffice\MSAccess.exe" "PathToDB\DB.mdb" /wrkgrp "PathToMDW\Secure.mdw"

To relink the tables automatically, you can create a button on a form and the
code it would execute can be found here:
http://www.mvps.org/access/tables/tbl0009.htm

Thank you, this is helpful.

If I'm reading this right, it sounds as if you believe that a virus would
target *just* the security files, and I'm guessing that's the workgroup file,
the MDW file, right? I don't believe there are any viruses that target just
MDW files. But maybe you mean the hard drive could be infected, so the data
on the whole hard drive would need to be replaced from backup, which would
wipe out all existing files.

No, I don't think that a virus would target the database or the security
files directly. I am thinking about the hard drive itself. One bad e-mail...

If you think Access User-level security is going to protect your database
from piracy, you are mistaken. Access security is easily broken by free
tools available on the web. People can open your database and make all the
changes they want.

I am so confused. I have been reading everywhere that care must be taken
when securing a database otherwise you could "lock" yourself out. But then,
it is believable since there are types out there that live and breathe this
stuff 24/7. This is not a highly sensitive database that requires
super-duper security. I am just trying to figure out the rules so I can play
the game.

They don't need a password if they have both the database file and the
workgroup file. If your application can be installed on one computer, then
it's unlikely that any customization you put in there will *prevent* it from
being installed successfully on another computer by someone who is determined.
What type of customization are you talking about? Hidden registry keys? A
password? The company name on forms and reports? These aren't difficult to
overcome, even with a secured database. If your compacted and zipped file
isn't large (< 5 MB), then you could send me the DB and MDW files, and I'd be
happy to show you the vulnerabilities.

I am thinking that if the database is passed on with the password, it would
be of little use to others because of the "company name, etc." on all the
forms and reports.

Well, I am going to try the back-up thing Rick was talking about (I hear XP
has a wizard...) and the CD thing that you are talking about to see which one
works best for my needs. Thank you both for your help. I'll let you know
what worked.

 

[Granny Spitz via AccessMonster.com]

No, I don't think that a virus would target the database or the security
files directly. I am thinking about the hard drive itself. One bad e-mail...

You're right. That's all it takes to ruin your day.

I am so confused. I have been reading everywhere that care must be taken
when securing a database otherwise you could "lock" yourself out.

Fear not. Knowledgeable people can still get in when everyone else is locked
out.

I am thinking that if the database is passed on with the password, it would
be of little use to others because of the "company name, etc." on all the
forms and reports.

It's usually soooo easy to circumvent this. If you create a new secure
database, create (or import) forms and reports (and their data sources) with
the company name on them and send it to me with the workgroup file used to
secure the database, I can probably change the company name to the name of
your choice. Would that convince you that the company name implanted on the
forms and reports wouldn't stop a pirate?

 

[Rick Brandt]

I'm just talking one more stab at this because I believe we are talking past
each other.

Your original post and subject line speak of "backing up a secured
database". The implication in that question being that there is something
inherantly different about backing up an Access file that has user level
security applied compared to backing up any other kind of file. First off
let me state that there is nothing at all different about it. You would
back up that file in exactly the same way you would back up any other file.

That reduces your question to "how do I back up a file?". While that might
be a legitimate question it is really not an "Access" question. I responded
that if the user of your program uses backup software to back up his system
there is no reason why that same backup software can't backup your files at
the same time. Along that same line of logic, if your user is currently not
backing up his system at all then why should he care if he backs up your
files? If his system goes down he is screwed anyway.

In your last post you had this...

This sounds good. Is backup software a brand or type? Do I just walk
into
a computer place and ask for backup software? I suppose there are 31
flavors
of this as well. Any suggestions?

Well, backup software is software that performs backups. Windows XP comes
with backup software built in. And yes if you walked into a software store
and asked the clerk for "backup software" he could likely show you an entire
aisle with nothing in it but different products for backing up computer
systems.

Now, if your primary concern is just to make a "backup copy" of the two or
three files that make up your application then any "backup software"
solution might be overkill, but most of them would have the advantage of
being able to be run automatically on a schedule rather that relying on the
user having to do something.

If you would like a button inside your app that makes these backup copies
then you have the problem in that you will be trying to make copies of files
that are currently "in use" and that is not an optimum way to make backups,
but if your routine made sure that no editing or saving was going on when
the copies were being made then I suppose you would get a decent copy 99% of
the time. Murphy's Law being the thing to worry about here.

The built in FileCopy command (I believe) will not let you copy a file that
is in use. I think though that you could use the shell command to execute
the DOS copy command on your files and that copy command would not care if
the files were in use or not so the copy would be made.

 

[aaron.kempf]

you can't backup MDB files when they are in use.

use an enterprise-level database