none
Conexion a SQL Server 2005 RRS feed

  • Pregunta

  • Estimados.

    Estoy revisando unos ASP y me he hecontrado que algunas conexiones estan con:

    DRIVER=SQL SERVER

    y otras

    PROVIDER=SQLOLEDB

    La verdad no entiendo del todo la diferencia.

    Saludos.


    DBA SQL Server Santiago/Chile

    martes, 3 de mayo de 2016 14:43

Respuestas

  • En realidad lo ideal es trabajar con un proveedor nativo para SQL Server, en este caso SQLClient, pero eso significa que el código de la aplicación tenga que modificarse porque las clases que dan soporte al proveedor son distintos entre sí. Ahora, yo te hablo desde el punto de vista de .Net Framework y los proveedores que soporta, es probable que las aplicaciones se hayan construido basados en otra tecnología que no da soporte nativo a SQL Server y por esa razón se opto por conexiones genéricas, es bueno primero te informes de las razones del porque decidieron trabajar con ese proveedor antes de hacer una sugerencia o reclamo anticipado.


    • Marcado como respuesta José De Alva lunes, 9 de mayo de 2016 3:21
    martes, 3 de mayo de 2016 15:57

Todas las respuestas

  • Hola CMAPM,

    Partamos desde el punto en que una cadena de conexión (connectionString) es el medio por el cuál una aplicación puede conocer su origen de datos: (proveedor de datos, servidor de datos, base de datos, credenciales, etc).  Para que una aplicación pueda comunicarse con los datos debe de hacerlo a través de un proveedor de datos y en el caso de .Net Framework trabaja con 4 proveedores (por lo menos son los que vienen de serie de hecho se puede conseguir proveedores para otros orígenes de datos como MySql): System.Data.SqlClient, System.Data.OleDb, System.Data.ODBC, y System.Data.OracleClient.

    Para el caso de System.Data.ODBC refiere al proveedor de datos por el atributo "driver", el proveedor System.Data.OleDb lo hace por al atributo "Provider" (por ejemplo un proveedor de base de datos en Ms-Access). Los proveedores nativos, por ejemplo System.Data.SqlClient no requieren definir el proveedor, pero ODBC y OleDb sí porque estos mecanismos podrían manejar diversos proveedores de datos: SQL Server, Orace, Ms-ACCESS, Archivos de Excel, etc.

    Finalmente, queda claro que sí trabajas con un origen de datos SQL Server se debería utilizar un proveedor nativo como System.Data.SqlClient y desechar los proveedores ODBC (Open DataBase Connectivity), ODBC crea una interfaz intermedia para "comprender" a los distintos proveedores con los que podría interactuar, esa capa intermedia es innecesaria si tienes claro que tu origen de datos es SQL Server y tienes un proveedor ad-hoc para conectarte a el.

    • Propuesto como respuesta José De Alva lunes, 9 de mayo de 2016 3:20
    martes, 3 de mayo de 2016 15:22
  • Entendido.

    Por eso con Driver SQL algunas veces hay problemas de memoria, hare que cambien a SQLOLEDB.

    Saludos.


    DBA SQL Server Santiago/Chile

    martes, 3 de mayo de 2016 15:38
  • En realidad lo ideal es trabajar con un proveedor nativo para SQL Server, en este caso SQLClient, pero eso significa que el código de la aplicación tenga que modificarse porque las clases que dan soporte al proveedor son distintos entre sí. Ahora, yo te hablo desde el punto de vista de .Net Framework y los proveedores que soporta, es probable que las aplicaciones se hayan construido basados en otra tecnología que no da soporte nativo a SQL Server y por esa razón se opto por conexiones genéricas, es bueno primero te informes de las razones del porque decidieron trabajar con ese proveedor antes de hacer una sugerencia o reclamo anticipado.


    • Marcado como respuesta José De Alva lunes, 9 de mayo de 2016 3:21
    martes, 3 de mayo de 2016 15:57