>Cetin:
>
>Thanks for the tip. I think that there might be 2 problems with it that I can't see how to overcome:
>
>1. with an outside file, how to add additional names and passwords without actually opening the file and doing it manually, and;
>2. more importantly, in the case where i am doing this on my own computer and not simply providing an application to someone else, what's to stop someone from simply going into the stored procedures of the database (within the project manager) and figuring out from there how to decrypt the outside file? Is there a way of "locking" the stored procedures so it cannot be opened?
>
>Thanks for your help.
>
>Paul

1) You'd open it programmatically, read/modify and save. ie:
(Untested off the top of my head)

*CheckPW
* Read file into a cursor
local lcTemp
lcTemp = sys(2015)+'.tmp'
StrToFile(Decrypt(FileToStr('myPasswords.dat'),'myKey'),m.lcTemp)
create cursor myPWs (cname c(20),PW c(20))
append from (m.lcTemp) type delimited
erase (m.lcTemp)

*AddUpdatePW
*...
*Write back added/modified cursor
copy to (m.lcTemp) type delimited
StrToFile(Encrypt(FileToStr(m.lcTemp),'myKey'),'myPasswords.dat')
erase (m.lcTemp)

If you think nanoseconds the file is written to disk and erased might be a problem there are other ways that you do this only in memory.

2) Stored procedures could be 'locked' deleting source entry and keeping only ObjectCode. Actually they wouldn't be able to open DBC in normal ways (dbc_OpenData kicks in).

However keep in mind that these only keep away regular users. An average VFP user wouldn't be stopped by this. There are ways to stop average VFP user too. Level of security is related how much of it you need and probably you'd get help from OS and maybe from MSDE,SQL server which are not 100% secure (unless you prevent physical access).

PS: If you make Check/AddUpdate into a COM class would provide more headache for the hacker. Add to that you might play with table headers making it one step harder.
Cetin