I'd normally store information of this nature (the expiration date) somewhere in the database and hide it (a profile document, a regular, but hidden document, or even a manually created design document). But since your users are developers and will have Manager access, that won't work, as they'll be able to see the document and remove it or modify it (even with the design hidden, there are techniques for finding hidden documents). So, my recommendation would be to store the information somewhere else. The obvious place would be in the Notes.INI. If your DB is going to be used on multiple platforms, this is a good place to put it, with a caveat - read below. If it's only a DB for use on Windows platforms, then a better place is the Windows Registry (easier to hide stuff). A third place is a hidden or even non-hidden file. In any of the above cases, you want to store the expiration date in such a manner that it is hard to find. There's lots of ways of doing this, but let me give you some suggestions: * Run @Password on the date before storing it (long date would be best, in fact)
* Store it in a file, registry key, or entry in the INI that does NOT look like it came from your application, attach it to Windows Paint's entry or something like that.
* Put the code to check the date in the Database Script element, which runs when the database starts every time.
* I'd put a checksum somewhere else that refers to the expiration date so that you'll know if the expiration date has been "removed" versus never being there in the first place. To do the work is very simple: 1. In the Database Script, see if the expiration date exists. If it doesn't, check to see if the checksum value exists. If it doesn't then you can assume that the code is being run for the first time.
2. If the code is being run for the first time, get the current system date and place it, encrypted in some way (it doesn't have to be elaborate, but shouldn't be stored visible). I'd just use @Password to generate a hash. Store the date, and store the checksum somewhere else.
3. If this isn't the first time the code is being run, then get the date, and compare today's date against it. If you're using a simple hash that you've devised, you can deconstruct the date to do a simple date compare in Notes. However, if you're using @Password, you will need to be a little more elaborate. A pretty easy way of checking for a date within 30 days using a hashed @Password date is to run a loop, starting with today's date and running backwards for 30 days. Do an @Password hash on each day in the loop and compare it to the stored string. If it matches anywhere in the loop, drop out of the loop, because you are still within the "trial" period. However, if it gets to the end of the loop without a match, then you've exceeded the trial period, and you need to notify the user and deny access to the database. To deny access, my favorite way is simply to change the ACL so that all entries are removed and the -Default- entry (which can't be removed) has "NO Access". If you've already set it up so that the DB has an enforced ACL, then this should completely deny access. One thing, though, I wouldn't send it out if the users have Manager access. I'd have them with Designer access. Really, the only thing Manager gives you over Designer is the ability to change the ACL or delete the DB from a server using the Notes Client. It looks like you'll not want them adjusting the ACL and if it's local, they can delete it using the operating system. Hope this helps!