Forget about this. DBC events aren't safe anyway. You can USE some.dbc as a table, go into the Code memo of the third record and change that source code, then COMPILE DATABASE. Or you can fiddle with the Property Memo of the first record to turn off DBC events, or simply empty the code Memo of the fourth record and thereby delete any code from the DBC, including all referential integrity code and triggers.

Using DBC events for protection of the tables is even less safe than protected Access mdb files.

Your dilemma is, that the only good product available encrypting data of a dbf is Cryptor, as Konxise, it's also from Xitech, unfortunatly it does not work in conjunction with Konxise, even though both products are from Xitech. Besides that Cryptor also it does not work with Vista, as far as Hallogram states here: http://www.hallogram.com/cryptor/

I've seen something in the fox.wiki to make Cryptor work in Vista:
http://fox.wikis.com/wc.dll?Wiki~CryptorOnWindowsVista~VFP

Still it doesn't work together with Konxise. Quoting Christof Wollenhaupt from http://www.foxpert.com/docs/security.en.htm:

"...If you need to protect data in a peer-to-peer network or you want to encrypt files before sending them to your users, there's only one tool available for FoxPro: Cryptor from XiTech...

...A further disadvantage of these tools is that Cryptor has to modify the jump list of DLLs. There are tools designed to prevent exactly this, because they either use the same trick, or because this behavior is typical for bad programs like viruses or worms. For instance, as of writing this, Cryptor does not work together with KonXise, even though both are from the same company..."

Bye, Olaf.