add a yearly license to a ms access (1 Viewer)
- Thread starter ferry
- Start date
arnelgp
..forever waiting... waiting for jellybean!
- Local time
- Today, 23:58
- Joined
- May 7, 2009
- Messages
- 19,248
there is similar discussion on the link:
Annual subscription requirement process | Access World Forums (access-programmers.co.uk)
Annual subscription requirement process | Access World Forums (access-programmers.co.uk)
Cotswold
Active member
- Local time
- Today, 16:58
- Joined
- Dec 31, 2020
- Messages
- 528
This does appear initially to be a great solution to licensing but is in fact a can of worms.
When I was in business and selling my software I looked into date validated licensing and decided it simply wasn’t worth the effort. It has to be totally solid in any situation but the reality is that you cannot guess just what could go wrong. If your system decides the license has expired the user is frozen out and even if that decision is incorrect you lay yourself open to a legal claim.
Where do you store the license data? In an Access file or another external file? If the license file is deleted or corrupted how do you check that? If your customer claims the system won’t work how will you check that it is a valid claim? Whilst you are checking, will the client suffer losses that you are liable for? In the past I found a dongle was a sound method of controlling licenses but not so good control in a Terminal Server environment. So I settled for my own license system that served me well for over ten years after abandoning the dongle and without any date related settings.
As a for-instance, only a few years ago I had a copy of Norton’s Anti-virus installed which decided after 7 months that the license had expired. It was impossible for me to fix that. Impossible to get Norton to acknowledge it. So I was left with having paid for 12 months but losing 5 months. I do doubt that you could create a license system that is more reliable or subject to more validation or testing than one from Norton Symantec.
Getting it to work is one thing but testing for everything that your inexperienced users could do to accidentally (or intentionally) break it, is something else totally. If you use a 3rd party software how exactly do you sort out an error if it is emanating from that software? Where are you if the 3rd party software doesn't work on an update of Windows11? What is the situation if you are unable to update their license on a specific date? Do you have any right to prevent a client from accessing their own data after their license has expired?
As have said, a can of worms and to be avoided.
When I was in business and selling my software I looked into date validated licensing and decided it simply wasn’t worth the effort. It has to be totally solid in any situation but the reality is that you cannot guess just what could go wrong. If your system decides the license has expired the user is frozen out and even if that decision is incorrect you lay yourself open to a legal claim.
Where do you store the license data? In an Access file or another external file? If the license file is deleted or corrupted how do you check that? If your customer claims the system won’t work how will you check that it is a valid claim? Whilst you are checking, will the client suffer losses that you are liable for? In the past I found a dongle was a sound method of controlling licenses but not so good control in a Terminal Server environment. So I settled for my own license system that served me well for over ten years after abandoning the dongle and without any date related settings.
As a for-instance, only a few years ago I had a copy of Norton’s Anti-virus installed which decided after 7 months that the license had expired. It was impossible for me to fix that. Impossible to get Norton to acknowledge it. So I was left with having paid for 12 months but losing 5 months. I do doubt that you could create a license system that is more reliable or subject to more validation or testing than one from Norton Symantec.
Getting it to work is one thing but testing for everything that your inexperienced users could do to accidentally (or intentionally) break it, is something else totally. If you use a 3rd party software how exactly do you sort out an error if it is emanating from that software? Where are you if the 3rd party software doesn't work on an update of Windows11? What is the situation if you are unable to update their license on a specific date? Do you have any right to prevent a client from accessing their own data after their license has expired?
As have said, a can of worms and to be avoided.
Last edited:
- Local time
- Today, 10:58
- Joined
- Feb 28, 2001
- Messages
- 27,195
First: Hello and welcome to the forum, at that is your first post.
Second: Cotswold gives good advice. There ARE licensing schemes out there but the legalities associated with such a scheme can be daunting. Here are a couple of threads that might be helpful.
Second: Cotswold gives good advice. There ARE licensing schemes out there but the legalities associated with such a scheme can be daunting. Here are a couple of threads that might be helpful.
How to create a unique license key for my access database
Hello everyone , I have a program which I need to distribute and need a way to create a unique license key for each device , What I have done so far is : I made a form in the db which pull HDD serial and CPU serial then combine them in one string with separator then encrypt the string using XOR...
www.access-programmers.co.uk
Annual subscription requirement process
I have designed a database and would like to restrict access based on a subscription. If they have entered a validation code, then the database opens. If not it drops to an error message. Code then keeps working until the specified time (12 months) then will require a new validation code. There...
www.access-programmers.co.uk
Assigning Licences for custom Excel/Access apps
Hi everyone, has anyone done this before? I’m considering developing a few simple but useful excel /access apps that I’d like to stop people from sharing with others… has anyone attempted to do a type of licensing system that prevents/deters copying? Leanne
www.access-programmers.co.uk
- Local time
- Today, 11:58
- Joined
- Feb 19, 2002
- Messages
- 43,305
There isn't a hot market for most business applications so theft is less of an issue than it is with "fun" things or more generalized applications that might be useful at home as well as at the office. A physical inventory is an example of something an employee might be tempted to steal for home use if it would work for a home inventory that is useful as a record for your insurance company.
The apps I sold were not shrink-wrapped so there was some training and custom support provided. I created what I called a token. It encoded a bunch of different things such as the expiration date, the number of concurrent audits, whether or not email was supported, and several other features. It also included a check digit which I placed at pos 8 out of 16 rather than as the last digit. We didn't try to control seat licenses. Six weeks before the token expired, the menu would change color and display an expiration warning.
I can't post any of the code but it wasn't really hard. There was a separate FE for generating the tokens. For each thing I encoded, I created an array of values and assigned logical meanings. I didn't use O, 0, or lower case l to avoid confusion. That left me 71 values for each character. Most of the options didn't take more than 3 so I allowed multiple values so that there might be 6 values that equated to expiration month but only 2 for exp day. In the "generation" phase, I generated a random number that generated a random value between 1 and 6 in the case of month. So if Jan was assigned values of 4, A, b, d, 8, Z and the random number was 3, then the token had a "b" for the month. On the other end, the translate table converted "b" to 1 for January.
The "token" was stored in a server table so it was available to all users. Each time the app opened, the expiration date was checked and the user was allowed to proceed or not. You can decide to allow read-only access if the token is expired and that is what we did. The data belonged to the user and we did not want to lock them out. However, the app would not do anything, including produce reports. It would just let you view client records but not change anything. The BE was not secured so the client could have access to his data directly if he wanted. The FE was locked down and technically no ordinary user would be able to get behind the scenes but the administrators could get into the BE but not the FE, that was locked down.
The apps I sold were not shrink-wrapped so there was some training and custom support provided. I created what I called a token. It encoded a bunch of different things such as the expiration date, the number of concurrent audits, whether or not email was supported, and several other features. It also included a check digit which I placed at pos 8 out of 16 rather than as the last digit. We didn't try to control seat licenses. Six weeks before the token expired, the menu would change color and display an expiration warning.
I can't post any of the code but it wasn't really hard. There was a separate FE for generating the tokens. For each thing I encoded, I created an array of values and assigned logical meanings. I didn't use O, 0, or lower case l to avoid confusion. That left me 71 values for each character. Most of the options didn't take more than 3 so I allowed multiple values so that there might be 6 values that equated to expiration month but only 2 for exp day. In the "generation" phase, I generated a random number that generated a random value between 1 and 6 in the case of month. So if Jan was assigned values of 4, A, b, d, 8, Z and the random number was 3, then the token had a "b" for the month. On the other end, the translate table converted "b" to 1 for January.
The "token" was stored in a server table so it was available to all users. Each time the app opened, the expiration date was checked and the user was allowed to proceed or not. You can decide to allow read-only access if the token is expired and that is what we did. The data belonged to the user and we did not want to lock them out. However, the app would not do anything, including produce reports. It would just let you view client records but not change anything. The BE was not secured so the client could have access to his data directly if he wanted. The FE was locked down and technically no ordinary user would be able to get behind the scenes but the administrators could get into the BE but not the FE, that was locked down.
