Out of (a) & (b) above, whichever falls earlier, displays a suitable message and causes the db to become unavailable for further use. 

    Count of uses is stored in a hidden table named T_Status. Even if the user gains access to this table, and tries to edit it, the overall settings are not easily disturbed as the criteria is linked to autonumber value which is controlled programmatically.

    Expiry date, start number and max permitted uses get embedded in VBA code - and therefore free from user interference, once the file is converted to mde.

Some interesting features for making the demo tamper-proof:
    1 - Essential values like TrialMode (Y/N), expiry date, max permitted uses, start value of autonumber, camouflaging offsets (for autonumber and date of last use) are hard coded in VBA module, which is not accessible to user in mde format.

    2 - Count of uses: 
    (a) Count of uses is tracked by autonumber value in table T_Status. It is a single record table and the record gets re-inserted after each use. 
    (b) Five digit starting value of this autonumber is generated on random basis and gets hard coded in VBA module.
    (c) The columns showing expiry date, max count and count of uses so far are redundant (mere diversionary role). Tampering of these values has no effect. 
    (d) If the user tries to interfere with autonumber value by re-creating the table, and the new autonumber happens to be less than the hard coded value of starting autonumber, the trial validity stands forfeited.

    3 - Additional safeguards:
    3.1 - A superstring made up of 55 digits is used to keep track of latest values of autonumber and the last use date. This string is generated by using random numbers. The autonumber and year / month / day parts of last use date are embedded within this string at different locations. As a further precaution, camouflaging offsets are added to the real values before implementing the embedment. These offsets, generated by using random numbers, are hard coded in VBA module. As a result, different copies of trial db, generated by using form F_LockSet, will have different values of offsets. Successful tampering of such a superstring is expected to be virtually impossible

    3.2 - The above super-string is stored in four separate ways as follows:
    (a) Database property
    (b) Project property
    (c) Registry key
    (d) Hidden system file in hidden system folder

    3.3 - On first run of trial db (signified by autonumber of table T_Staus being equal to hard coded value of starting autonumber coupled with the absence of database property, project property, registry key and special system hidden file), items 3.2 (a) to (d) above get created, duly populated with the superstring.

    3.4 - On each closing of form F_SwitchBoard, existing value of autonumber in table T_Status is incremented by one and along with current date, is embedded in freshly generated 55 digit superstring.

    3.5 - On each opening of form F_SwitchBoard, validity check is performed, covering:
    (a) Current autonumber in table T_Status should not be lower than the hard coded value of starting autonumber.
    (b) None of the special settings (database property, project property, registry key and special system hidden file) should be missing.
    (c) None of the four superstrings, stored in 3.2 (a) to (d) above, should show any sign of tampering and all the four superstrings should be identical.
    (d) Autonumber values as extracted from the superstrings from four different sources should all match the one in table T_Status.
    (e) Last use dates as extracted from various superstrings should equal each other and should never be higher than current date. This is meant to guard against re-setting of system clock backward.
    (f) Current autonumber should not exceed the value computed by adding max permitted uses to starting autonumber (both these settings are hard coded in VBA module).
    (g) Current date should not exceed the expiry date (hard coded in VBA module).