Hi Bob,

I think I misread your point.

Of course, there must be a certain leap of faith given the developer. It is akin to one's accountant knowing the real state of one's financial situation, or the payroll master who has knowledge of all the payrates of a company's employees. We, also, are privy to how a client conduct his business since we need to know their business rules.

If a client, however, does not want their developer (us) to know the database UID and Passwords, they can easily just change them at the backend server, then notify the users of the change in their connection/access info. Client also has option to change the encryption key, thereby 'relieving' us of access. It is like change the locks in their house doors/gates.

Cheers!
Dennis


>Hi Dennis,
>
>Do the developers know where this DBF File is? If so, what would stop the developer from using the DBF in another application
>and popping up a messagebox with the information that is returned? UID/PWD etc after it is un-encrypted?
>
>So my argument is that there has to be a certain level of trust that is given the developer...
>
>Thanks!
>Bob
>
>
>
>
>>Robert,
>>
>>Outside of me giving the DBA my source code, showing him where to change the SQL Server user ID and password and having him compile it himself... Does anyone have any ideas??
>>
>>We usually use a DBF which stores all pertinent connection info (the fields are encrypted as well). Then, we provide a form interface for the client to change User ID, password, server IP etc as they wish. This DBF is read by the app as it establishes a connection with the database server.
>>
>>Others store connection info in the client machine's registry.
>>
>>Hope to help.
>>
>>Dennis