APPLICATION TO BE USED BY ONLY ONE COMPUTER (1 Viewer)

[Michelle Michy]

Hi all. In my research over the web I found the following function. I don't know how to call it in a module or submodule. Any assistance will be highly appreciated. I want my access database application to be used by only one computer.

Public Function LDSerialFSO(DriveLetter As String) As Variant

On Error GoTo errHandler

Dim objFSO As Object
Dim objDrv As Object
Dim strSN As Variant

DriveLetter = Left(DriveLetter,1) & ":"

Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objDrv = objFSO.GetDrive(DriveLetter)

If objDrv.IsReady Then
    strSN = objDrv.SerialNumber
Else
    strSN = Null
End If
    
LDSerialFSO = strSN

errExit:
    Set objFSO = Nothing
    Exit Function
    
errHandler:
    MsgBox Err.Number & ". " & Err.Description
    Resume errExit
    
End Function

 

[CJ_London]

If you want help, please stop shouting (using all capitals)

 

[The_Doc_Man]

If you know the serial number of the intended computer's disk then in an autoexec macro you could run that code to see if the stored disk S/N and the actual (running) disk S/N are the same serial number. The autoexec macro would basically have to do a RunCode to a function to evaluate the serial number and compare it to the intended serial number. Then either keep on working or do an Application.Quit

 

[Michelle Michy]

If you know the serial number of the intended computer's disk then in an autoexec macro you could run that code to see if the stored disk S/N and the actual (running) disk S/N are the same serial number. The autoexec macro would basically have to do a RunCode to a function to evaluate the serial number and compare it to the intended serial number. Then either keep on working or do an Application.Quit

Thanks. Is there any code to detect the serial number?

 

[Michelle Michy]

I want to send my application through email. The user should not be able to copy after using it in one computer. Thanks in advance.

 

[561414]

I don't know how to call it in a module or submodule

That should be called from a form event, such as Form_Open. The setup should include going into Options, then Current database, then choosing a form to open automatically when the access file is opened. The form that you choose will be where you call your LDSerialFSO function from.

So, where do you plan to store the valid serial numbers?

 

[plog]

A form of this question has been asked multiple times on this forum (prevent copying, expire functionality after a certain time, limit the use based on some criteria, etc.). You can search at the top right of this page, but let me save you some time:

There is no effective way to do this.

And in 99.9% of the cases no real reason to do so. What is your fear? What do you think you will gain if you could do this? I understand not wanting your hard work to be stolen, but the amount of hard work involved in trying to implement what you've asked for is usually more than the hard work that went into the original product development.

 

[Michelle Michy]

A form of this question has been asked multiple times on this forum (prevent copying, expire functionality after a certain time, limit the use based on some criteria, etc.). You can search at the top right of this page, but let me save you some time:

There is no effective way to do this.

And in 99.9% of the cases no real reason to do so. What is your fear? What do you think you will gain if you could do this? I understand not wanting your hard work to be stolen, but the amount of hard work involved in trying to implement what you've asked for is usually more than the hard work that went into the original product development.

I give up.

 

[561414]

To be fair, if that database is sent to users who don't know anything about Access, implementing a validation of this kind will have some effect, a very small one, but it's OK to try. It will be bypassed easily with the simple holding of the shift key as the file opens, among so many other ways, but who knows? maybe they will achieve some results.

Just an opinion.

 

[Michelle Michy]

To be fair, if that database is sent to users who don't know anything about Access, implementing a validation of this kind will have some effect, a very small one, but it's OK to try. It will be bypassed easily with the simple holding of the shift key as the file opens, among so many other ways, but who knows? maybe they will achieve some results.

Just an opinion.

In my application, you will not bypass by holding shift keys because I disabled it by VBA code.

 

[561414]

I can't/won't list all of the methods to break into an Access database. Just know that anything you try will be hackable with relative ease.

 

[theDBguy]

It's interesting how the copyright notice was removed from the code despite the explicit request to keep it intact.

How to Retrieve the Hard Disk's Serial Number

I found myself looking for a way to retrieve the serial number of the computer's hard drive as a way of preventing unauthorized copies of an...

thedbguy.blogspot.com

 

[The_Doc_Man]

If you absolutely have to do it, the function to detect the drive serial number is what you presented in post #1. That function would, if called, return the drive serial number as a string. The catch is that there is no relatively untouchable place to put that string for future comparison. If you have a total chowderhead on the computer in question, it might be safe. If you have anyone who is somewhat astute, the odds of this standing up diminish. The Shift Bypass trick would stop an AutoExec macro from running, but if your app requires a legit form to comfortably use it, you can put your test code in your startup form or switchboard form OnOpen event code. The OnOpen event can be canceled, which would prevent the form from opening. You would still need to know that you must do an Application.Quit, though.

There is an old rule: What Man can build, Man can destroy. Plog's comments about other topics to search might be enlightening. As 561414 said, your success will depend on the abilities of the user against whom you are protecting.

 

[gemma-the-husky]

The easiest way is to get a user to send you a piece of information that is unique to their computer, and for you to create a response to that information that will allow them to continue. They store that response (a license key) that will work only on their computer.

If they can't guess the correct response they won't be able to activate and use the application, so you make it hard to work out how you are accomplishing this.

Now if a user changes his pc, and asks you to update his licence, how do you know he isn't just trying to install your application a second time?

 

[Isaac]

To be fair, if that database is sent to users who don't know anything about Access, implementing a validation of this kind will have some effect, a very small one, but it's OK to try. It will be bypassed easily with the simple holding of the shift key as the file opens, among so many other ways, but who knows? maybe they will achieve some results.

Just an opinion.

I agree.
"Effective" is a whole range of subjective levels of satisfaction

 

[Pat Hartman]

@Michelle Michy Without knowing how you intend to distribute the application and later update it and whether or not it is multi-user, etc., it is really hard to come up with a solid plan.

The way many software installations work is by having the software communicate with a web app during installation to log a piece of information relating to the installed computer and then checking each time the software logs on to find a match. So, once an "instance" has been registered (this would require saving a property to the actual .accdr, if that is even possible) and then each time the app opens, it would need to "phone home" and compare the data retrieved from the computer, such as the serial number of the hard drive, with the value stored in the web app and if they match, the app is opened and operational.

The web app also keeps track of the number of licenses. So, if the user is paying for 20 licenses, only twenty PCs can have a piece of unique information stored on the web and only those twenty will ever be able to log on. You have to provide a method of removing one PC and letting a new one register but you would handle that manually. The users couldn't do it.

 

[Michelle Michy]

@Michelle Michy Without knowing how you intend to distribute the application and later update it and whether or not it is multi-user, etc., it is really hard to come up with a solid plan.

The way many software installations work is by having the software communicate with a web app during installation to log a piece of information relating to the installed computer and then checking each time the software logs on to find a match. So, once an "instance" has been registered (this would require saving a property to the actual .accdr, if that is even possible) and then each time the app opens, it would need to "phone home" and compare the data retrieved from the computer, such as the serial number of the hard drive, with the value stored in the web app and if they match, the app is opened and operational.

The web app also keeps track of the number of licenses. So, if the user is paying for 20 licenses, only twenty PCs can have a piece of unique information stored on the web and only those twenty will ever be able to log on. You have to provide a method of removing one PC and letting a new one register but you would handle that manually. The users couldn't do it.

Thanks so much.

 

[isladogs]

There is another approach you could consider which in some ways is similar to how M365 licensing works.
Instead of trying to prevent multiple installations, limit the number of simultaneous users to the number of licenses purchased.
Say your client has a license for 3 workstations, then once that number of users are logged into your database, no one else can login until a user logs off. Its relatively simple to code and also relatively difficult to bypass. It also has the advantage that the client may decide to purchase additional licenses if they often hit the limit.

Whilst I agree that no security measures will ever be 100% secure from an experienced and skilled hacker, you can certainly make it difficult enough that most people won't bother. However, the shift bypass can easily be re-enabled. Don't rely on it alone

 

[Cotswold]

Using specific computer details can be problematic. If a valid user has to change their PC how do you police that? One night their PC is stolen, or simply breaks down. How do you know if that isn't baloney? It's OK for the likes of Microsoft because they aren't particularly worried about upsetting you if you'll have to buy another licence.

In the olden days, the dongle was the easiest solution. You bought the dongle, wrote the codes into it for a client and issued it. My programs wouldn't run without it. If they wanted more users, then they had to buy another dongle. If they lost a dongle they had to buy another. Simples.
All you need to do is to create an electronic dongle. I created one but it required them to telephone to complete the install with codes I gave them. Which today you probably wouldn't want.

 

[isladogs]

@Cotswold
The approach I outlined in post #18 solves the problem outlined in your first paragraph.
I also use an activation approach which is the equivalent of a dongle. On first installation, the application sends hardware info to me from which I supply an activation ID to complete the process.
Still not impossible to hack but certainly quite difficult to do so.