1 2 Previous Next 18 Replies Latest reply on Oct 30, 2009 5:00 PM by philmodjunk

    Trial period for my database

    MOHSSUITE

      Title

      Trial period for my database

      Post

      Is there a way to make a demo version of my database expire in 30 days if it is not purchased.  Also, can I program my database to expire on a annual basis so my customers have to get a code to continue use of the database?  I wrote the database in FMP 7, but am currently running FMP 8.5.  I am willing to upgrade to FMP 10 if it makes a difference.  Any help would be great.  Thanks.

       

        • 1. Re: Trial period for my database
          philmodjunk
            

          In File Options, you can choose to have a script run each time the file is opened. This script can be set to check the current system date against a date stored in the database and ask for an activation code, display an error message or some such action when the current date indicates it's time to do so.

           

          Here are two possible If statements that could be used. Many other variations on this are possible:

           

          If [YourTable::YourDateField + 30 < get (CurrentDate) /* 30 day expiration */]

           

          If [YourTable::YourDateField + 365 < get (CurrentDate) /* 1 Year expiration */]

          • 2. Re: Trial period for my database
            mrvodka
              

            I prefer storing the initial date / time in a field and then test against a spread from that date and time. This way the user could not just change their system clock backwards to get around it.

             

             

            • 3. Re: Trial period for my database
              philmodjunk
                 You can also add such date tests to various critical function scripts so that playing games with the computer's system clock may get the files open but still leaves the database crippled.
              • 4. Re: Trial period for my database
                MOHSSUITE
                  

                 

                Thanks for the valuable advice.  Two quick, and perhaps basic, questions.  1. Once the the program expires, how do I reset it for another year. 2. How do I store the initial use date/time in a field.  I assume that is the initial date the database was opened?

                Thanks for all of your help.

                Ben


                 

                 

                • 5. Re: Trial period for my database
                  philmodjunk
                    

                  Answering 2 First:

                   

                  In you're on open script:

                   

                  If [isempty(yourtable::RegistrationDate)]

                    #put code here to control how you want users to register the software

                    Set Field [ yourtable::Registrationdate; Get ( currentdate ) ]

                  Else

                    #check the date as shown earlier

                  End If

                   

                  Note: some developers use more sophisticated techniques to store the date outside the file so that users can't install a new copy and then import the data from the expired copy.

                   

                  Answering 1:

                  WHen the script detects that the file has expired, it can use SHow Custom Dialog or switch to a special layout where the user must enter a code you supply. If the entered code is valid, then update the stored date with the new date, using Get ( currentdate ).

                  • 6. Re: Trial period for my database
                    MOHSSUITE
                      

                    Thank you very much.  I for some reason have limited capacity when it comes to this.   Can I ask one additional question? 

                    How do I establish an initial registration date?

                    Thanks.

                    Ben

                    • 7. Re: Trial period for my database
                      philmodjunk
                        

                      See my previous post:

                       

                      If [isempty(yourtable::RegistrationDate)]

                        #put code here to control how you want users to register the software

                        Set Field [ yourtable::Registrationdate; Get ( currentdate ) ]

                      Else

                      .

                      .

                      .

                       

                      What this code does is set a an initial registration date if there is no registration date recorded.

                      • 8. Re: Trial period for my database
                        MOHSSUITE
                          

                        I will give it a try.  If I can't figure it out, is there any way I can hire your services?

                        Thanks again for the uber fast response.

                        • 9. Re: Trial period for my database
                          philmodjunk
                             I've sent you a private message. Check the evelope icon in the upper right corner.
                          • 10. Re: Trial period for my database
                            DLW-BPEX
                              

                            mr_vodka and PhilModJunk,

                            Pardon my denseness, but I seem to be missing something.

                             

                            1. Aren't both of your schemes doing the same thing? i.e., storing an initial date and later comparing that to the user's current system date?

                            2. How does that initial date get generated to populate the field? Won't it need to vary according to when a given user downloaded (or first opened) the file?

                            3. How is the user prevented from defeating this by setting his clock back?

                             

                            Thanks for any further clarification.

                            David 

                            • 11. Re: Trial period for my database
                              philmodjunk
                                

                              If you read back, you'll see that the on open script checks for a date in a date field. If it's empty, it stores the current date. That's how it logs the original date the file is first opened.

                               

                              You are correct that the method I described can be defeated by playing games with the computer system clock. That's why I suggested building this date test into various critical function scripts so instead of just when the file opens. This keeps the user from setting their clock to a past date, opening the database and then re-setting the clock date.

                               

                              Since auto-entered date information also references the system clock, many database solutions will not be viable if the system clock is not set to the correct date.

                               

                              I'm not sure from Mr. Vodka's response what exact method he is recommending. Perhaps he could elaborate?

                              • 12. Re: Trial period for my database
                                mrvodka
                                  

                                Get ( CurrentDate ) and Get (CurrentTimeStamp) returns the current date that is set on the system clock. So if lets say we stored on 1 October 2009 the initial date, 30 days one would figure it would expire on 31 October 2009 ( 30 day expiration ).

                                 

                                If the check happens every time it loads and uses: YourDateField + 30 < get (CurrentDate), if they switched the system clock back to 10 October 2009, then it would be valid.

                                 

                                If you capture every time that the user has accessed the file when opening and exiting ( or when they perform an action ), you will get a log that will dictate when the user last accessed it. So every time the spread will shrink until it runs out. You would test against this each time. Since you are using a timestamp, even if the user decides to roll back the date and or time, it would be annoying because they would have to do it a bunch of time a day. Every single time you go to log the timestamp, if properly used by the user, the timestamp would increment forward not go back.

                                 

                                • 13. Re: Trial period for my database
                                  DLW-BPEX
                                    

                                  Ah, yes. It made perfect sense when I first read it the other day, too. But a little while ago I was focusing on your reply above the one with the On Open script. Your "date stored in the database" of course was simply the current date originally stored when the field was still empty. I was confusing that with mr_vodka's "initial date" which presumably already is in the database somehow(?).

                                   

                                  You spotlight a good point about problems resulting from a reset clock. Not really a good deterrent unless the user is aware of the risks. But certainly that raises awareness for the developer that bad things can happen to the database just because the user is gaming the system.

                                   

                                  Thanks again.

                                  David 

                                  • 14. Re: Trial period for my database
                                    philmodjunk
                                      

                                    I think we're describing variations on a similar theme here. Nothing wrong with Mr. Vodka's variation.

                                     

                                    What I was describing works like this:

                                    I have a database system that prints invoices. If I gave it an expiration date, a user could change the system clock and open the file, but since all invoices record the date they were printed, if the user prints any invoices, they have the wrong date. A clever user could figure out that they can set the clock back, open the file and then reset the clock to the correct date. However, if my script for printing invoices also checks for date expiration, the user still gets an expiration notice and the system shuts down.

                                     

                                    I like Mr. Vodka's approach for this imaginary database, because I'm already logging dates each time an invoice is printed. It'd be pretty easy to store the maximum and minimum dates in an auxiliary table and trigger an expiration when MaxDate - MinDate > 30.

                                    1 2 Previous Next