>Suppose I have created program from VFP. I would like my users
>input their passwords in my program 's table. My objective is :
>I don't want others people who know VFP to see my passwords ' table
>from opening VFP program. I want password table can open or see only in my program.
You have several approaches; none of them are entirely satisfactory. You can encrypt the content of the table and/or field, so that the field is viewable, but the content of the field is not intelligible without the appropriate decryption routine. There are both commercial and public domain encryption routines that can be called from VFP; at least one, CRYPT.FLL, can be downloaded from UT I think.
The problem here lies in the fact that a VFP table is a normal file; if the user can open the file for reading with any program, including your own, it can be opened from another by the same user. A determined user can access your table with another tool (things like Excel, other database programs like Access and the like can open a normal VFP table either through native drivers, ODBC, or via DAO or ADO. Even if steps are taken to hide or manipulate the headers of the VFP table to prevent it from being opened normally, tools like hex editors can still access the content; reading is reading, regardless of who does it. There is no specialized access control built into VFP; it relies on the operating system to provide security.
Another approach that would work well in an NT Server environment would be to access the table via a remote OLE Server. The server runs on a separate machine as remote, out of process OLE Automation Server, and then you would have the operating system restrict direct access to the file to only that machine. The OLE Server then must provide an interface for your app to request reads and writes to the table. Ordinary users on other machines would not be able to open the table, since the table would not be visibly shared - only the OLE server interface could access the table. This could be written in VFP, but you would not be able to manipulate the table except via the OLE interface - you would not be able to access it from other programs except through the OLE server.
If security is a real issue, a move to a client/server environment like SQL Server is probably most appropriate. SQL Server and other similar products provide field and table level security, and through server stored procedures could ensure that only your application could open the tables, read or write values. Using remote views, you can make the server database manipulable from within VFP using standard VFP commands. The problem here is that client/server databases like SQL Server are not free, and the coding on the server side would require learning the server's database language as well. SQL Server 7 is clearly targeted at this market, and will be available inthe relatively near future; MS has announced formal pricing for the product in the past week or so.
