Prev: Joining two tables after manipulating a field
Next: How do I handle a Transport Error
From: jc on 18 Jul 2008 11:04
We installed this new Application.. The vendor insisted we use a
common (single) SQL users for the ODBC dsn system entry..

Is there any way to enforce that this user/password is only used with
that ODBC entry and not a a sql client.

Can we log in SQL server 2005 by IP.. Say a table is suddenly missing,
how will we know who did it? If through the application or from a sql
client?
From: Eric Russell on 18 Jul 2008 11:28
Perhaps the vendor suggests a single SQL Server login account in order to
implement connection pooling. This account should have minimal permissions;
do not add it to the datareader or datawriter roles, just grant it exec
permisisons on the procedure calls it needs. The PW for this SQL Server
account should be stored in web.config or a DSN on the server and not
supplied to the users. If the users are to login to the application, then use
windows authentication or a forms based login form.

"jc" wrote:

> We installed this new Application.. The vendor insisted we use a
> common (single) SQL users for the ODBC dsn system entry..
>
> Is there any way to enforce that this user/password is only used with
> that ODBC entry and not a a sql client.
>
> Can we log in SQL server 2005 by IP.. Say a table is suddenly missing,
> how will we know who did it? If through the application or from a sql
> client?
>
 | 
Pages: 1
Prev: Joining two tables after manipulating a field
Next: How do I handle a Transport Error