Good call, Uncle Gizmo. Database attribute is indeed one way to do this.
rahulgty, you can modify the source string that appears in a database module if you want, but you cannot COMPILE and SAVE the code that results from this change while you are yourself RUNNING THAT SAME CODE. I.e. like the cartoons where a character saws off the tree limb on which he is sitting, you will have a rapid fall to a sad situation. The TECHNICAL reason you can't do this is because the code object is open, therefore cannot be overwritten. It is LOCKED. You have to be in design mode to be able to do this. Which means EXCLUSIVE ACCESS to the module.
Here's another thought, not to be tried unless you are willing to get your hands really dirty digging through the documentation. There are some two-input hashing algorithms that might be useful. They let you input one number and the system derives another number from a parameter you can try to read. Like using code to read registry keys to find the serial number of the disk on which the code is installed, or at least the hardware cpu serial number. You might wish to look up hashing algorithms which can be found in network DLL files so that you could input a string, read another string from the registry, and generate some sort of key.
You might also wish to consider PKI infrastructure. It is possible to have self-generated PKI certificates that you could use to encrypt something. In the latter case, you would self-generate a PKI cert. Then use your private key and this e-mailed value you mentioned to generate a string. You can include your public key in your product to service the decryption step that would allow your code on the user's machine to check that it's on the right box.
I.e.
1. User's CPU s/n --> emailed to you.
2. You encrypt CPU s/n with your private key.
3. You send encrypted output back as product key.
4. Your startup screen asks for key, which your user enters as the product key. You can even store this literal value in a table. If there is a value in the table already, maybe you DON'T ask for a key until you try it first.
5. Remember, your product can "know" your public key. (That's why it is called a PUBLIC key...)
6. Using public key and the encrypted copy of CPU s/n, DECRYPT the user-input string - which should symmetrically decrypt back to the cleartext CPU number, and compare it to the CPU s/n. If the CPU actual s/n matches decrypted CPU s/n, allow other things to happen. If not, ask for another key.
You can even STORE the encrypted key in the DB because without your private key to convert it, it doesn't matter whether or not anyone can see it. Just don't store the decrypted version.
Hope that was clear.