Creating a TRIAL version

[charper]

I've built a nice a system for a potential client. They won't know whether or not they want to buy it, of course, until they've had a chance to use it and put it through its paces. Therefore, in order to protect myself, I need to provide them with a trial version of this system that will expire after a certain amount of use.

I can think of about 100 different ways to set this up, but I'd like some input on what the best (and easiest) approach is. Should I base it on ellapsed time? This seems rather complicated and seems vulnerable also. Users can just set their system clocks and dates to anything they want and bypass the ellapsed time logic. Is there a way to prevent this? What's a good algorithm for an ellapsed time approach?

I also considered just counting the number of times they click on tab buttons that take them to different files. But then they could bypass this by navigating between files without using my tab buttons (by manually switching between file windows inside the FM app window.)

I'm also considering counting the number of times they cause scripts to run that generate reports. Each report script would increment a counter by one and when the counter hits 20 or 30, block access to the entire system.

What about giving them a user ID with only certain access priveleges? I'd rather not limit the Trial version to only certain functions or layouts, but if I chose these limitations carefully, it might be ok. One thing they really want to be able to do later on is to

have remote access using either FM Server or Webcompanion. Can I block them from using any remote access capabilities without blocking other critical functions? Basically, I want the trial version to allow editing, deleting and creating new records and allow access to all layouts. I could allow this level of access and block things

like exporting and script editing, etc. that they won't need to use in the trial version but might need later on - seems kinda weak.

[Chuck]

One way to get around people resetting the clock might be to have a field that counts the number of times the solution was launched on a different day. Increment this field by 1 every time a launch happens on a day that it hasn't happened before, and make it so that when a certain number is reached, it won't continue. If it's a multi-user setup, you'll need to use a normal field in perhaps the main menu file rather than a global field.

Theoretically, this could be circumvented also, if the person changes the day to the same day every time they launch the system, although since they don't know the mechanism for the time bomb, it would be unlikely. Another possibility that wouldn't care if the date of the computer was changed is to track the number of launches. How many users will use the system? Let's say five. If each of them open the system once a day, you can give about a week of use by tracking the number of times the system is opened and if that number is greater than 25, don't allow access.

These are just ideas off the top of my head. I've never had to come up with such a solution before, and there are certainly better ideas out there from people who have.

Chuck

[LiveOak]

How about just limiting the maximum number of records allowed (use a new record button and a message) and putting "Demo Version" in light gray in the background of every report layout?

-bd

[proton]

I don't know how often you design solutions with those needs you listed, but if you do it fairly often, there are solutions that allow you to time-lock your filemaker databases. I think Troi makes one of them, check them out. Just a thought.

[SteveB]

For starters check www.databasepros.com, John Mark Osborne's site. He has a couple of easy to implement scripts. It should be enough for you to implement a reasonably comprehensive protection scheme