shareware database with free use expiring

[tedmillerx]

should be a nifty little ap. however, i'd like to set it up so the user can use it for only 30 days. after that he's got to buy the permanent access code from me or else the software freezes up.

i'm not really sure i need to worry about making it super-secret/variable. it'll be pretty cheap and I don't think many people will steal it.

I've got Access developer XP.

how do I set up the standalone MDE file to have a siezure in 30 days, but one you can fix by entering an activation code?

 

[jrbarnett]

What you have to do is record the first date it was used - maybe store it in a User system table with basic encryption so it isn't immediately obvious to any snooper what it is (ie they could edit it).
You then check each time the program loads up for the existence of a valid registration code. If you don't find one, use this date with the DateAdd function to work out if this date plus 30 is below today's date and if so, display a registration screen which has two options: Enter registration code or quit.
You could also make the enter registration code screen available elsewhere, so those who legitimately pay for a code can enter it without having to wait for the program to expire and ask.

John

 

[MrMcFestoe]

try here

http://www.utteraccess.com/forums/s...=239939&page=0&view=collapsed&sb=5&o=&fpart=1

sorry, if you are not registered you will need main page, but this guy has done it and it even tells the user if they alter the systems time & date.



Life is made on the decisions you make not the chances we take.

 

[tedmillerx]

jrbarnett -
thanks for the advice. it's exactly what I'll do.

MrMc-
couldn't see into that site. looks like they're doing some maintenance right now.

 

[MichaelRed]

Almost ANY reasonable programmer can find their way around the startup code/object of almost any Ms. A. app. Having done so, the "startup" code is readily available. The only pratical approach would be-in my opinion- to implement the full Ms. A. Security on the app. As PART of that, you would need to restrict most access to all objects -even AFTER the appropiate registration. If the security is properly implemented, you should have no need for the encryption -as you would NEVER permit any access to the 'table' with the registration information.

Then, all you need to do is make each registration unique to the specific installation -to prevent copying a (ONE) properly registered copy from becomming universal.

Now, you would have a 'reasonably' secure item, but need to consider the various (and oft whimsical) desires of the clientel. Such as making all of theis work regardless of the (obviously OPTIONAL) installation parameters (e.g. drive and path of the app).




MichaelRed
m.red@att.net

Searching for employment in all the wrong places