It depends on the access the program will have with the database. If they only need to read data, you could configure the users in SQL to only grant certain permissions for specific actions and database objects. For example, you have one client that needs read access ot their data reports, make sure they only have SELECT access to the table (or view) that they will need.

You may even wish to go as far as creating a server application on your side that acts as a proxy between the client and the database, ensuring that their requests are indeed valid and that they never have access to the underlying database. It might not be necessary, however, but it's an option if you're running a zero trust policy.

Most likely NOT. Why? If you're sending raw SQL over the line, it's fairly easy to capture that traffic (via Ethereal, et al). So that means that someone could intercept the login, and use it to DOS your server by sending queries that take a very long time, or at worst, send DROP TABLE (hopefully you have the accounts set so this is not possible though).

That situation is highly unlikey if you've properly set up your permissions server-side. In short, make sure you set the bare minimum permissions on your database server. Give each of the clients a specific username/password that they'll need to enter into your application and maintain these permissions on your database. Also, make sure you keep an audit trail, just in case.

Yeah, the real place where you'll be able to set security is at the database. Get an account set up on your database that gives the user only the permissions they need, no more. Make permissions read only wherever possible. If behavior is forbidden by the database, it will be difficult for a hacker to do anything too terrible. You might seek out your dba's advice on this.