Transfer Database into Protected project

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have several clients using my db that has pw protected code. From time to
time I create additions and updates to the db and would like to upgrade their
copies using "DoCmd.TransferDatabase". The complete file is very large and
hard to email.

Problem... I cannot find a way to include the password for the protected
code so that the "DoCmd.TransferDatabase" will work. A sample of code that I
use on unprotected db's is below: Thanks in advance.

********
strDB = "C:\NT\NTxx.mdb"
Forms!FrmUpdateNTI.txt1.Caption = "Updating"
str = "fMemRsvLate1"
Forms!FrmUpdateNTI.txt1.Caption = "Adding Color Formatting"
DoCmd.TransferDatabase acExport, "Microsoft Access", strDB, acForm, str,
str, False
********
 
Not to answer your question, but, the standard way to provide code
updates, is to split your database into a so-called "front end/back
end" or FE/BE structure. With an FE/BE structure, the BE database
contains all of the data but none of the code, & the FE database
contains all of the code but none of the data. The FE just has links to
the actual data in the BE. So to provide a code update, you just give
them a new FE, and they copy that directly over their old FE.

If you google the Access groups for those terms, you'll find lots more
information.

HTH,
TC [MVP Access]
 
Thanks TC. I do have a FE/BE database. My clients are in several different
states and the FE is about 15 meg. That is why it is difficult to email the
entire FE. I can zip but I want to avoid any problems on the client end.

Transfer database works perfectly when the project is not protected. I have
been searching the Access groups for an answer for some time now. Maybe there
is not a way to pass the protected code password.

Thanks again.
 
Hi, Rusty.
Problem... I cannot find a way to include the password for the protected
code so that the "DoCmd.TransferDatabase" will work.
Click to expand...

There's a trick to it. Open the password-protected database from the
current database by using a new instance of the Access Application object,
and then import the new objects with the TransferDatabase( ) method. For an
example of the syntax, please see the link to the tip, "How to import objects
into a database secured with shared level security from another database," in
the Security section of the following Web page:

http://www.Access.QBuilt.com/html/how-to_tips.html

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
See http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.

- - -
If my answer has helped you, please sign in and answer yes to the question
"Did this post answer your question?" at the bottom of the message, which
adds your question and the answers to the database of answers. Remember that
questions answered the quickest are often from those who have a history of
rewarding the contributors who have taken the time to answer questions
correctly.
 
Owwww that is a biiig front end!

Maybe you could build an auto-update capability into the FE. On each
start, it could check your website for evidence of a new version. If
found, it could download the new version using FTP, then use windows
APIs to copy the new one over the current one (which requires a restart
to take effect). That way, the whole process could be automated,
reducing the chance of user error. And you could do all that from VBA.
If you designed it carefully, you could make it an
application-independent module, that you could drop straight into any
front end that you wanted to.

Of course, you'd need for the user to opt-in to this process, and be
able to reject the download if he wanted to.

I'm considering adding something like this to one of my products. Not
because my front ends are big - just because it would be advantageous
to me, and the user, to have this process automated.

HTH,
TC [MVP Access]
 
Hi 69 Camaro,

I am closer to what I need to do more so than ever. Your solution almost
works. My database has evolved since Access version 2.0 when security was a
real pain. I have my own security built in which works very well for us. All
I need to do now is work around signing in to the db that will receive the
update. I think I can take it from here.

Many thanks for your help.
 
TC,
Thanks for your help. I think that "69 Camaro" has given me a path to
follow. We are not FTP'ing files at this time but I will consider using your
sugggestions in the future.

Thanks again.
 
Hi, Rusty.

You're welcome. However, the only problem with homebuilt security is that
it's so easy to open the database file by holding down the shift key so that
the startup code doesn't execute. In case you disable the shift bypass,
anyone can re-enable it because everyone has a copy of the same workgroup
you used when disabling the shift bypass.

Good luck.

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
See http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.
 
Further to what Gunny said, the other problem with "home brew"
security, is that there is nothing stopping anyone from creating a new
database, then using the OpenDatabase() method to view, edit or delete
the data in /your/ database.

Cheers,
TC [MVP Access]
 
TC and Camaro 69,
Thanks for taking the time to give the feedback.

In most every case, what you both say is exactly correct. However, the
database FE cannot be imported to a new database without the password for the
code project. That's the same reason that I cannot get the
"DoCmd.TransferDatabase" to work when I only want to update one or two forms
in the code protected FE.

I am not concerned that the data in the BE can be copied because it belongs
to the client anyway.

My home built security uses registry settings, and an .mde library that also
houses the "disable shift" code. I do not depend on a workgroup file for
security. So far, the security seems to be solid. But, I'm sure there is
always a way to break most any type of security where there is a will and a
skill.

I do appreciate the help. Thanks.

Rusty F
 
Rusty F wrote:

I am not concerned that the data in the BE can be copied because it belongs
to the client anyway.
Click to expand...

That's a really good point - often overlooked, in my opinion.

My main product has all sorts of checks & balances, to stop the user
running it illegally on more PCs than he has licenced it for. But he
can copy the back-end (data) database where-ever he wants, how ever
many times he wants. This is on the principle you state above: the
actual data is his - not mine.

TC [MVP Access]
 
Correct. Thanks again for the help.

--
Rusty F


TC said:
Rusty F wrote:

I am not concerned that the data in the BE can be copied because it belongs
to the client anyway.
Click to expand...

That's a really good point - often overlooked, in my opinion.

My main product has all sorts of checks & balances, to stop the user
running it illegally on more PCs than he has licenced it for. But he
can copy the back-end (data) database where-ever he wants, how ever
many times he wants. This is on the principle you state above: the
actual data is his - not mine.

TC [MVP Access]
Click to expand...
 
Back
Top