How to COPY-PROTECT Access Application

We use a method that I wouldn't call copy protecting but it does tend to prevent casual users from breaking into the database itself.  As stated above a determined, knowledgeable user will eventually break into the database.  Our database is locked so only the database owner can open it to expose the underlying tables, forms, and code.  All users must login with their own password and they are presented a main form that when exited terminates their session.

This doesn't prevent a user from copying the database to another lan or to their own PC but since it is multiuser by nature their is no real advantage to them to do so.

I agree with the comments above.
Develop a good working relationship with all your customers.
Be responsive to their needs.
Provide upgrades periodically.  
Mainly you need to make yourself relatively valuable to your customers otherwise they may look elsewhere.

good luck
mlmcc

"....
Making a .mde will protect your code and hinding tables and database-form the next obvious protection
...."
i could agree with you but you don't hide tables.
In that case, shift key can be disabled also.

Thanks for your comments everyone.


My application is designed for local law firms in Barbados. I will be having them sign a licence agreement which (among other things) prohibits copy and distribution. With the larger firms I am not too worried about copying. The smaller firms I'm not too sure about. But I'm fairly certain that the application will not be subject to the manipulation of a knowledgeable access user, simply becuase there's no such person down here.So I'm really looking for a simple form of copy-protection against the unsophisticated user.


Given my intent and what I've learned from your comments and from checking Access Help. Here is what I plan.

1. SPLIT my application into two files using the wizzard
2. Convert the file with only forms into an .mde.
3. Hide the table and form files in different locations in the hard drive and put a short cut on the desktop only for the "Forms" file.


One question though. Will my "Forms" file be able to find my Table file if they are in differnt locations if I split the DB using the wizard?

Looking forward to any further comments suggestions.

Thanks Kan

When you have splitted the database in a front-end a back-end, then the tables will be linked and will have to be relinked when the back-end is placed on a different location.
Best way to go is to use the network address of the backend, otherwise you'll get "tangled up" with the possible different driveletters a user can have.

A small additional "copyright help" might be to print this on all reports together with the name of the firm having the license. Having this on every footer and coming out of the code behind the report will make it harder for others to use it...

Nic;o)

If you will install your app by yourself, you could use the disk-serial approach. I mean, every HD has its own serial number, you could manage it to do really custom installation.
If you save the disk-serial information (in a property of some from/class, registry, cryted, and check for it every time app is running, sure the app will not works over other HD, hence other PC.
It has a backward, if disk is formatted or broken, you have to do the installation again by yourself.
Hope it helps.

Nic;o and Richie Simonetti

Nic;o
So I will have to recconnect every table. That may be arduous. As far as putting the name the licencee on the reports I can't do that b/c the reports are replicas of government issued forms. But some of the forms require information about the user. So I will be hardwiring the required information about the user into various reports, thereby limiting the use of those particular reports to the specific user, but most of the reports/government forms do not require user information. Ps. Thank you for pointing me in the direction of the .mde.


Richie,

Your idea re: the hard drive serial number is EXACTLY what I had initially invisioned. I would love to use your approach, since I will always be installing the software myself and installation is not tediously time consuming. Please tell me more about how to go about using your this approach. I have another 150 points left and I would gladly add them to the value of this question if someone could walk me through applying your approach regarding getting access to confirm the serial number of the hard drive each time my application/db is opened.

Many thanks to both of you.

Kan

Well, create a macro called autoexec that would runs this code:

Private Declare Function GetVolumeInformation Lib "Kernel32" Alias "GetVolumeInformationA" (ByVal lpRootPathName _
As String, ByVal lpVolumeNameBuffer As String, ByVal nVolumeNameSize As Long, lpVolumeSerialNumber As _
Long, lpMaximumComponentLength As Long, lpFileSystemFlags As Long, ByVal lpFileSystemNameBuffer As String, _
ByVal nFileSystemNameSize As Long) As Long

Public Function CheckSerial(ValSerial As Long) As Boolean
' You need to check  if is first run. If so, save Serial value on
' some place. It will be used as parameter to this funcion
' next time.

Dim Serial As Long, VName As String, FSName As String
    'Create buffers
    VName = String$(255, Chr$(0))
    FSName = String$(255, Chr$(0))
    'Get the volume information
    GetVolumeInformation "C:\", VName, 255, Serial, 0, 0, FSName, 255

If ValSerial Mod Serial = 0 Then
    CheckSerial = True
Else
    CheckSerial = False
End If

End Function

Note that it is a generic routine, it must be ameliorate to your needs. If you cannot by yourself, let me know, i will be glad to help.
Cheers

Hi Kan,

Your comment:
>So I will have to recconnect every table.
is a bit "too" harsh. All that's needed will be the activation of the linked table manager under the tools menu. When the frontend is installed on every individual machine you'll need to do this once, but when the frontend is situated on the server, this might disturb the use for other users when the drive name isn't for all the same. Using the \\... network reference will solve this.

Nic;o)

Hi,
One of the things I do to protect the Db from being moved is a make a seperate DB with a table that has a field with a number in it. I then make this DB password protected and save it as an MDE. Now in my main DB I link the MDE with something like MSysDB_Key. The code to look as this table is on the form that you open the DB with. On the open event for that form place the following:
Dim rs As DAO.Recordset
Dim db As DAO.Database
Set db = CurrentDb()
 Set rs = db.OpenRecordset("MSysDB_Key", dbOpenDynaset)
 rs.Edit
 If rs!KeyCode <> 5452 Then
 MsgBox "No Key Code found for this software"
 rs.Close
 Quit
 End If
 rs.Close

 This may not be the best approach but it does prevent a user fram taking the DB to another machine. The table can not be linked unless you know what is the password and you can also hide the DB. Also I make the field not visible.
Hope this helps.

Hi Puzzledby,

See you're new so welcome to EE.
It's customairy to post comments iso answers, as that will keep the questione better visible in the "to be answered" section and doesn't force the questionner to take action.

Please read the lines at the bottom...

Nic;o)

Hi,
One of the things I do to protect the Db from being moved is to make a seperate DB with a table that
has a field with a number in it. I then make this DB password protected and save it as an MDE. Now in
my main DB I link the MDE with something like MSysDB_Key. The code to look as this table is on the form
that you open the DB with. On the open event for that form place the following:
Dim rs As DAO.Recordset
Dim db As DAO.Database
Set db = CurrentDb()
Set rs = db.OpenRecordset("MSysDB_Key", dbOpenDynaset)
rs.Edit
If rs!KeyCode <> 5452 Then
MsgBox "No Key Code found for this software"
rs.Close
Quit
End If
rs.Close

This may not be the best approach but it does prevent a user fram taking the DB to another machine.
The table can not be linked unless you know what is the password and you can also hide the DB. Also
I make the field not visible.
Hope this helps.

Well, i have a mdb file if you want to try my approach.
Cheers

Well, this is one possible implementation:
In your mde file  create a table, i called it LocalCfg with two fields
RecordId     ->Long
StartDt          ->Date

You  need to add a macro called Autoexec, action: Run code (or execute function,
i don't know since i have Access in spanish, sorry). The function that this macro would
execute is: CheckIfIsCopy.

In a module:
Private Declare Function GetVolumeInformation Lib "Kernel32" Alias "GetVolumeInformationA" (ByVal lpRootPathName As String, ByVal lpVolumeNameBuffer As String, ByVal nVolumeNameSize As Long, lpVolumeSerialNumber As Long, lpMaximumComponentLength As Long, lpFileSystemFlags As Long, ByVal lpFileSystemNameBuffer As String, ByVal nFileSystemNameSize As Long) As Long


Public Function CheckIfCopy()
Dim serial As Long
Dim rs As Recordset
GetVolumeInformation "C:\", vbNullString, 0, serial, 0, 0, vbNullString, 0
Set rs = CurrentDb.OpenRecordset("select * from LocalCfg", dbOpenDynaset)
With rs
    If .RecordCount < 1 Then
        CurrentDb.Execute "insert into localcfg (id,Startdt) values(" & serial & ",#" & Now() & "#)"
    Else
        If serial Mod .Fields("id") <> 0 Then
            MsgBox "License not Found", vbInformation, "Init Fails"
            Application.DoCmd.Quit acQuitSaveNone
        End If
    End If
End With

End Function


If you use ADO, changes are required but the idea is basically the same.
PS: Don't forget to disable Shift key

I use a simple direct and different approach.  I set up a table of the client details.  I set up a module containing the client details, which I then make invisible.

On start up of the splash screen I compare the table with the client details to the module.  If they do not match the software has been priated.  At that point the software destroys the modules responsible for all calculations and the hidden module.  Simultaneously I send an email with details of the changed client details to my computer.

I then distribute as an MDE file.  This means a simple hack job of the backend would deactivate the entire code, and tell me who was doing it (provided they are connected).

Hi kkan, any progress/need more help? Just ask.

dynamictiger, i am not the King of THE Truth, sure there are several approaches to get it work.

Hi everyone.

I am VERY grateful for the multiple suggestions. I have however been busy with a few bugs that my tester seems to enjoy uncovering and I have not been able to direct my attention to my copy protecting.

I apologize for the delay in my response but will get to this as soon as I can.

Incidentally I favour Richie Simonetti's approach and intend to use it if I can get it to work.

Richie:

Please email a copy of the mdb file at containing the exaple of you approach to:

cariblaw10@netscape.net


Many thanks again to everyone.

kan

Hi puzzledby.

Thanks for your suggestions. It's actually an approach I also considered. (Creating a linked table with a field containing a verification/code number). The problem that I came up with is that most if not all of my clients will be using access only for my application. So in order to copy my applicatoin all the user would have to do is search and copy all access mdb, mde files and then copy those onto another computer. Please let me know if I misunderdtood your suggestion.

Thanks Kan

Richie Simonetti,

Just checking in to see if you had an opportunity to email that sample to me. I checked my email but is was full so I hope your email didn't bounce. I have emptied it now so it shuold be able to recieve mail.

Looking forward to your reply and I hope that you had a good week end.

I was indeed at weekend i will email you mdb as soon as possible.
Cheers
PS: here is 1:00 AM Monday, i think i could sent it to you by 9:00 AM when i would be at Office.

Thanks Richie

Looking forwarding to getting your email.

Hi kkan,
You are correct in that they can copy all mdb's and mde's but they must also relink the tables and they must also be in the correct folders. If the mde is password protected then the table can't be relinked if they do not know the password. I also make the main mdb into a mde with password protection. The mde can also be hidden by setting it's attribute. I also turn off the option in access not to show hidden tables or system tables. It would be nice to make the hidden table into a mda pointing to code imbedded into the registry but the same can be done with a mde. Even further have the mde place the hard disk serial number in the same table. Then make a compare of the Hard Disk SN with that in the mde.
Of course a knowledeable person with a just a little difficulty would be able to hack this approach.
Thanks for the comment!

My apologies for awarding you the points so late.

Been and continue to be extremely busy.

Many, many, ,many thanks.

Kan