Creating Sample App with limited number of records

[kstieb]

I have just finished creating a nice vfp program. I would like to post it on my web site as a "fully working demo", that restricts the main table to 25 records. The table name is "members".
....
I "could" allow the users to input more than 25 records, and then when the program exits it would delete all but the first 25...However, most demo programs I have seen will not allow you to save more than 25 records (if that is how they have it set).
....
What is a good method to handle this???
Likely a good FAQ posting as well!

 

[audiopro]

Why not delete all but the first 25 records on start up?
It would appear to them that they are deleted on shutdown but would stop them using the app if they found a way round your shutdown routine.
I would make it clear to them that their new records will be deleted in the demo version only but that there is no limit if they part with some cash.

Keith

http://www.studiosoft.co.uk

 

[Mike Lewis]

Another possibility would be to add code to your "new record" routine. The code would check RECCOUNT(), and if it is 25, display a nice friendly message to say they can't add any more records, and which would include information about how they can purchase the full copy.

That way, you achieve your aim of restricting the record count, and you also encourage sales of the full product.

By the way, when you put a VFP app on a web site for people to download, you also need to give them the VFP runtimes, and a suitable setup program or some other mechanism for installing the app. This could add up to a lot of megabytes (sorry if that's obvious).

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[GriffMG]

Depending on how you handle deletes, you might want to pack your table on entry.

Be warned though, even limiting the number of records allowed might not be enough to stop a user from taking full advantage of a nice little VFP application!

You might want to time limit it as well, and/or limit the number of uses...

Good luck

Regards

Griff
Keep [Smile]ing

 

[kstieb]

Thanks for the advice to all of you. Yes, I am using RECCOUNT() to limit the number of records in the table. It seems to be the most elegant way to do it. I use ProMatrix framework, and there are a few neat "extra" procedures and functions with it that help make this coding pretty easy to do.
I am also going to incorporate the delete all but first 25 records on startup, just in case someone decides to bypass the front end code (or think they will).
I know creating demo programs is a bit of a pain for programmers. People are always looking at ways to bypass the restrictions.
From my perspective, I like having a fully functional demo program to look at before I make a purchase. Ones that do not allow you to try out all the functions make me nervous to purchase.
What I intend on doing is allowing 20 records for the demo program. It is enough to get the feel for the program, but not enough to use the program permanently.
As for size of program....well, it will not be that big when compiled and in distribution mode. So should not be a problem to download.

 

[keepingbusy]

In addition to some of the previous posts on this thread (Mike and GriffMG), I got around the use of demos/limited versions by including something simple as below in the startup PRG for time limits:

* Time limit

IF date()>ctod("01/06/2007")
   =messagebox("Demo version has expired. "+ ;
     "Contact Seller etc"+space(10),0+64+0,"System Message")
   QUIT
ENDI

* In another PRG or whever is appropriate,
* put the below in your source code where you add records

USE MYTABLE
IF RECCOUNT()=25
   =messagebox("Demo version - Maximum records "+ ;
     "Entered. Contact Seller etc"+space(10), ;
   0+64+0,"System Message")
   RETURN
ENDI

It may look very easy but it works.

Good luck
Lee


Windows XP
Visual FoxPro Version 6 & 9

http://www.customsoftware.co.uk

 

[Mike Lewis]

Lee,

Maximum records "+ ;
"Entered. Contact Seller etc"

The way you coded it, you are slinging them out of the app as soon as they start the relevent program or procedure.

Wouldn't it have been better to let them continue, but to prevent them from entering more records. That way, they can continue to evaluate the other functions of the app.

Also, I'm not sure about imposing both a record limit AND a time limit. My inclination would be to impose the record limit, but to let them evaluate the app for as long as they like. But that's just my opinion.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[keepingbusy]

Mike

The way you coded it, you are slinging them out of the app as soon as they start the relevent program or procedure.

Correct me if I'm wrong, but don't most demo/limited version apps do that when the demo expires?

Wouldn't it have been better to let them continue, but to prevent them from entering more records. That way, they can continue to evaluate the other functions of the app.

How long would it take to enter 25 records? The way I see it Mike is that you can give them as long as you feel is appropriate. This could of course be 30, 60, 90 days etc with the ability to use the program but with a maximum of X records.

Also, I'm not sure about imposing both a record limit AND a time limit. My inclination would be to impose the record limit, but to let them evaluate the app for as long as they like. But that's just my opinion.

I appreciate and respect your opinion (as always Mike), but whilst I don't want to go down the copyright avenue here, I have had a "previous experience" where perhaps some "enquirers" have used demo versions with extended time, lets say for there own ends. I think you know where I'm coming from here.

Depending on the app, the amount of records and length of time allowed to use the demo, my thoughts are it really depends on what it is you are offering and to who.

Lee

Windows XP
Visual FoxPro Version 6 & 9

http://www.customsoftware.co.uk

 

[Olaf Doschke]

some additional thoughts:

the limited table should be opened shared or exclusive all the time the application runs, or else one might exchange it after startup.

reccount() counts deleted records too, so to be fair recycle delted records with RECALL or PACK the table.

If someone has VFP or uses the OLEDB Provider he can add more records at runtime. DBC events can be turned off. It's really hard to protect a DBF really from any manipulation.

So it may be a good idea to have some addiional place, eg in the registry to store some checksums or encryption calculated. You store them if it's the demo version and records are added/deleted/changed with the app, and check when reading record. Any manipulation from outside the app can be detected.

Bye, Olaf.

 

[audiopro]

Another way would be to store a default set of records within the app as simple vars. On start up, pack the whole table and create new records from the vars. This would allow the demo to operate with all the features working but would be useless for use in any live application.

Keith

http://www.studiosoft.co.uk

 

[Mike Lewis]

Lee,

I don't really disagree with what you say. It really depends on what type of application this is, what type of user, what the selling price is, and how advantageous it is for the user to subvert whatever protection system you have in place.

My own inclination is to err on the side of permissiveness. That is, I'd rather give the potential customer more opportunity of evaluating the software, with fewer restrictions, even if it meant some of them might postpone, or even avoid, buying the full product.

But I fully accept that that attitude won't be appropriate for all developers and all types of software.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[Imaginecorp]

We do this with our evaluation copy of our complete application with all functionality switched on with unlimited records. In one of our apps we add 100,000 records, at install, from an encrypted file, to prove its power and speed. (In my experience, a blazing fast app with 100 or so records will be slow and kludgy with 100,000 unless it has been tested with that many. You want your app to be recommended to others. Nothing like word-of-mouth.)
The evaluation copy is good for 30 days. When the app is first installed it writes the date (scrambled) to some numbers. Every time it starts it checks todays date against the hidden date. If not found the app will not start. Once the date is reached it displays a message asking if they want to extend the evaluation period for another 30 days? If no the app uninstalls itself.
if Yes it deleates all tables and recreates them adding the necessay records. This is to make sure all decision makers have a chance to evaluate our applications at their leasure.
Unfortunately with our clients, business decisions may, some times, take between 6 months to a year.
I know this is not the answer you are looking for but I do reccomend a time limit and a friendly message...just proves your app is user friendly.

 

[Olaf Doschke]

The record limit is for one of the tables ("members"), so it does not imply any limit to other tables...

It can be a very good idea to limit web a community software to N members to make it free for small private communities. You still can test the power of the application...

Bye, Olaf.

 

[Mike Lewis]

Imaginecorp,

Your approach is exactly what I had in mind. I especially like your way of letting the customer overcome the time restriction.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk