And of course you'll want the table hidden and/or designated as a system
table using the USys prefix for the name. Along with that, you can come
up with a way to encode the crap out date by using an alternate means of
storing the date instead of the typical m/d/yyyy format. I would suggest
using the 100 year format since not many people would recognize the
value as such esp if the field in which it is stored doesn't have the
name 'DATE' in it. To that end you could even go so far as adding random
numbers before and after the actual value which are extracted using the
Mid() function. For example,
928342938652983738457234987239492423
Would be the value used if today (4/15/2005 as 38457 in 100yr format) is
the expiration date. To extract the value,
Mid(strValue, 16, 5)
Mid("928342938652983738457234987239492423",17,5)
Then convert it to a date
CDate(Mid("928342938652983738457234987239492423",17,5))
The nice thing is that you can setup code to create the string when the
application is first started. If the value is NULL create it, otherwise
ignore it.
David H
P.S. Of course if you really wanted to make it difficult, you could use
an algorithim that splits the 100 year value into each of its component
values 3, 8, 4, 5, 7, and places the digits randomly in the value with
the locations encoded set locations in the string.
In the example below, the leading 10 digits indicate the physical
location for the values and serve as pointers for the Mid() functions
that will extract the values
1436294226928342938652983738457234987239452423
intPosition1 = CInt(Mid(strKeyValue,1,2))
strDigit1 = Mid(strKeyValue,intPosition1,2)
....
dteDate = CLng(strDigit1 & strDigit2 & strDigit3 & strDigit4 & strDigit5)
Character Positions Value 100yr Digit Value
1-2 14 3
3-4 36 8
5-6 29 4
7-8 42 6
9-10 26 7
14 36 29 42 26 928 3 42938652983 7 38 4 572349 8 7239 4 52423
Digit Positions
The nice thing with this is if some one tries to tinker with the value,
there's a good chance that they won't be able to figure out what to
change in the value to override the expiration date. Since the *mde file
will lock down the algoithm, they'll have play a lot to get it to work.
Additionally, if you wanted to sell them the product, you could email
them a new value that has a value of say (1/4/2050) encoded and instruct
them to copy & paste it in.
3041261122928342938652983738457234987239452423
Character Positions Value 100yr Digit Value
1-2 30 5
3-4 41 4
5-6 26 7
7-8 11 9
9-10 22 2
(I've had SOME sugar this evening.)
Nikos has a point. I checked the link and it has some decent ideas. Someone
will always try to find a way to defeat you. I do have an idea, but like any
other, it is not bullet proof.
Put a table in your mde with one row. Name one field [Date_Installed] and
the other, [Date_Last_Used].
When you create the mde to send out, be sure both fields are empty. Then,
in whatever form or macro, etc you run when the app loads, do this (air code):
if [Date_Installed] = "" then
[Date_Installed] = Date()
[Date_Last_Used] = Date()
endif
if date() < [Date_Last_Used] then
someone set the clock back, slap them silly
make them go away
end if
if dateadd("d",30,[Date_Installed]) <= Date()
[Date_Last_Used] = Date()
ok to run
else
make them go away
end if
The advantage here is that you don't have to remember to go in and change
the date in the code each time you send it out, and the user won't be upset
he did not get his full 30 days because shipping took too long.
The one downfall is that if a user changed system date before each
execution, he could defeat it. How likely is that? Usually, they don't do
that until it stops working. But, as I sit and think, adding a maximum uses
in the above table and checking it would offset that problem. I would be
generous in case someone cranks it up several times a day.
And, as I think further, you could add some code that if this is a demo
version, do a "nag" screen that would give them order info or a chance to
enter a code (you would supply code on purchase). then add 2 more fields,
one that you could check the code against and one that would be Yes/No to
update when the code is entered and check it before you do all this other
stuff.
If this is not sufficient, I would suggest that after 30 days, go to the
user's house with a shotgun. If he is still using the app, demand payment.
If he doesn't pay, blow a hole in his computer. I suggest aiming for the
hard drive.
:
Many thanks guys.
This helps very much. Klatuu, I am very much interested in your findings,
please share.
Thanks again
:
