Can a runtime soln be set to expire (stop running)

[GoTigers]

I'm wondering whether a runtime soln can be set to disable after a set period of time. Thank you!

[Reed]

Do you mean that the application will quit after some time being open. Or do you mean a demo version that won't launch after some expiration date?

[GoTigers]

I mean a demo version that has an expiration date. Thanks!

[QuinTech]

Maybe create a field named FirstRunDate and have an opening script that goes:

If ( IsEmpty ( FirstRunDate ) ) 

  Set Field ( FirstRunDate , Get ( CurrentDate ) ) 

Else

  If ( Get ( CurrentDate ) > FirstRunDate + 30 )

    Exit Application

  End If

End If

This will allow the user to run the application for 30 days after the first time they run it.

J

[-Queue-]

System dates can easily be changed to bypass such limitations. I ran the FM 7 demo for nigh on half a year by changing the date just before opening it.

It is more reliable to use a counter field for the number of times the solution has been opened and auto-close the file after the counter matches the desired maximum.

[QuinTech]

JT! Good to see you back! Even if it is with an admission of piracy! (Just kidding.)

Good point, though. A marginally savvy user could get through that with ease.

[-Queue-]

I admit nothing, except that I was poor and happened upon the hack quite by accident...

It's good to see you again, too, Jerry. It appears as if you're still the resident jester (or is that elf)?

[Oldfogey]

I have spent many hours pondering this problem - how do you stop those rotten, crooked users from using your software after the trial period? So have many others - there are a few threads on this topic.

The solution is not a technical one; it is psychological - or something. As Queue pointed out, it is fairly easy to break the date thing. No matter what you do, some mongrel will break it. (No offence, Queue.) Accept it! The vast majority of people are honest. Do you realise how much energy we spend worrying about the crooks? Ignore them. Use a stored date, or whatever else you like. Crooks and poverty-stricken students will break the 'code'. So what? Most people will pay up. All you need to do is make it as bit difficult. For example, in one of my client's DBs, I use a master password of 'Development' with an automatic default (of 'DE'); the staff are all too lazy to make the effort to key in 'Development', unless they really need to do something, which is probably OK - they're lazy but almost competent. (Like me.).

Spend your energy on creating carrots for the users who pay.

[-Queue-]

Touch

[GoTigers]

Thanks to all these wonderful ideas. Our users are very computer un-savvy , so a simple deterrent will be more than adequate, but the more complex solns are worth pondering! I appreciate the time you've taken to respond to my inquiry!