Disabling a sub based on an expiry date 1

[Creosote65]

Hi all,

I would like the simplest and most straightforward means to disable a subroutine based on the event date. Let's say that the expiry date for the subroutine is January 1st, 2005. I would like the command to function until that date. Should someone use it after that date, I would like them to receive a popup stating that the function has exceeded it's expiry date.

Thanks,
Creosote

 

[SkipVought]

Hi,

Sub MyProcedure()
  If Date > #10/4/2004# then exit sub
'the stuff my procedure does

End Sub

Skip,
[sub]
[red]Be advised:[/red] It's been reported that a wee psychic is roaming the countryside.
Small Medium @ Large! [/sub]

 

[Creosote65]

Hi Skip!

Short and sweet, the way I like it!

Thanks,
Creo

 

[jsteph]

Creosote65,
Be aware that this is easily circumvented by changing the system date temporarily. Is this for some sort of 'Trial Period' enforcement? If so, there are other methods you might use.
--Jim

 

[Creosote65]

This for job security. I suspect that I might be leaving the organization when my project is completed. If this is the case, I am planning on having the timer kick in around next February. I would like to explain, but I'll give you the gist: this is not malice, it is retribution.

I have also invoked the SetBypassProperty function. I believe that the combination of the two will cause the intended problem, since this is a multi-user database.

However, any further suggestions are definitley welcome.
Creosote

 

[Elysium]

If possible, why don't you have the sub-routine read an external source for the date, or even some other type of key. That way, you're not dependent on a 'local' machine.

 

[jsteph]

Creosote,
I've done things of that nature--strictly for 'Trial Period' uses, using a VB executable as a proxy stub to run the Access mdb.

Be aware that no matter how strong you may feel your case for retribution is--what you are doing could be illegal and if it causes enough disruption--your employer could sue you. Just the cost to hire a lawyer and mount a defense is more trouble than a typical individual (especially if that individual is without a job) wants to go through

Having said that, you need to know that Access is highly hackable--anything like that in the code can and will be found if the disruption is big enough. It can be as simple as putting a date-check or some other algorithm in a small VB executable. The vb executable is not hackable, as a general statement (some strings, etc, embedded in .exe files can be rooted out, however). But once the Access app is hacked, then nothing outside can prevent anyone from changing whatever check-code is expected.

But going further, I have, (for complete code-hiding) passed the Access.Application object to a vb exe, then making ALL logic, calls to forms, reports, etc. happen in vb. The app was basically a VB app with an Access db for both data and forms, reports, etc. But there was nary a shred of code in the Access.mdb itself. If I had something in the VB app that didn't like either the date, or the number of times it was used, etc, then it could stop and nothing else would get past that.
--Jim