Solo lectura DB Connection Strings

Question

Esto parece una pregunta muy tonta, pero he tenido una búsqueda y no puedo encontrar nada al respecto.

Tengo una cadena de conexión DB que estoy creando en mi web.config: -

<connectionStrings> 
<add name="DBConn" connectionString="Data Source=<db svr>;Initial Catalog=<dbname>;Integrated Security=True" providerName="System.Data.SqlClient /> 
</connectionStrings> 

o

Data Source=<db svr>;Database=<db name>;User ID=<uname>;Password=<pword>; 

pero necesito que esta conexión sea de sólo lectura. He definido todos mis objetos linq con solo obtener sus propiedades, y ninguna de las clases de repositorio (MVC) tiene métodos .SubmitChanges() en ellos, así que estoy 99% seguro de que el sistema no puede actualizar este DB, pero también me gustaría establecer mi conexión de BD para ser RO si es posible. Me doy cuenta de que idealmente esto debería hacerse en el extremo del servidor SQL y el usuario debería estar en RO, pero eso (por diversas razones, fuera de mi control) no se puede hacer, así que quería bloquear mi conexión a medida que la aplicación no debe escribir en la base de datos.

¿Hay un parámetro de "solo lectura" que pueda aplicar a la cadena de conexión para que arroje un error o descarte los datos si se intentaron actualizaciones?

Solo para reiterar (la primera respuesta que tuve, al preguntar esto, en otro foro fue "cambiar tus credenciales de base de datos") No puedo, de ninguna manera, cambiar las credenciales de acceso a base de datos, estas son RW y cualquier intento de cambio ellos (actualmente) bloquean la base de datos del servidor SQL. Este no es mi problema, y ​​no puedo ver cómo resolver ese problema, así que es por eso que quiero ver cómo hacer la conexión de DB RO, ya que tiene que matar absolutamente a cada ... errr, quiero decir absolutamente, positivamente no puede cambiar los datos de DB.

Saludos

MH

Answer 1

Lo que tienes bajo tu control es el código de acceso a las clases (L2S). Sugiero anular en una clase parcial los SubmitChanges para su datacontext para no hacer nada (¡o incluso lanzar un error!) (O implementar todos los métodos de extensibilidad InsertObject, UpdateObject o DeleteObject que pertenecen a su datacontext)

Answer 2

No, no hay manera (que yo sepa). Desafortunadamente para usted, la forma correcta de hacerlo sería cambiar las concesiones del usuario actual, o crear un nuevo usuario con solo privilegios selectos. Me doy cuenta de que esta no es la respuesta que está buscando, pero tener un servidor Sql que se cuelga cuando intenta cambiar las cosas parece ser un problema que realmente vale la pena investigar. ¿Es porque estás usando la cuenta "sa" para conectarte? De ser así, debería crear otro usuario y otorgar los permisos apropiados al nuevo usuario.

Answer 3

Realmente depende de qué base de datos y proveedor de DB está utilizando. Algunos permiten el acceso de solo lectura en la cadena de conexión, otros no.

Por ejemplo:

SQL Server 2005 CE, cuando se utiliza el proveedor de datos de .NET Compact Framework para SQL Server Mobile, tiene un parámetro posible File Mode=Read Only;. (ver en connectionstrings.com).

SQL Server 2008, doesn't.

Puede ver más en connectionstrings.com.

Answer 4

no hay nada que pueda hacer en el nivel de cadena de conexión que evite escrituras que no sean las de cambiar al usuario, lo que ya ha dicho que no puede hacer.

En ese caso, simplemente tiene que hacer lo máximo en su código para evitar cualquier escritura; es decir:

• cualquier capa pública no debe exponer la semántica de actualización/eliminación/inserción o lo que sea.
• hacer ninguna clase de capa de datos cerrados, de manera que no pueden ser invalidados

Sin embargo, todavía hay nada que impida a un programador de venir a lo largo de, arrancando la cadena de conexión, y pegándolo en el interior de su propia conexión para realizar escrituras.

Por lo tanto, podría mover la cadena de conexión a otro lugar que solo el código interno sabe cómo acceder (de todos modos, seguirá siendo un archivo de texto, ¡no use un código constante!); todavía no impide que nadie lo use, pero lo hace mucho más difícil.

(agregado) Debo explicar por qué no lo protege.

Dejando de lado que es probable que la fuente de la cadena de conexión sea accesible, incluso con protección con bibliotecas de encriptación, etc., no hay nada que me impida reflejar su código y llamarlo, aparte de los niveles de confianza. Puede optar por recorrer toda la ruta de ofuscación para evitar que deconstruya su código; pero seguramente este nivel de paranoia no se requiere dentro de su casa de desarrollo?

En última instancia, sin embargo, porque es 'SEP' (problema de otro), como usted dice, y no tiene control sobre eso - si alguien le pregunta por qué, a pesar de sus mejores esfuerzos, no se puede garantía que no se realizarán escrituras, puede culpar a ese "alguien más".