Ejecución simultánea y ADO.NET

La ejecución simultánea en .NET Framework es la capacidad de ejecutar una aplicación en un único equipo que tenga instaladas varias versiones de .NET Framework sin que esto afecte a la propia aplicación. Es decir, aunque haya varias versiones de .NET Framework disponibles en un único equipo, la aplicación utiliza aquella para la que se ha compilado y no se ve afectada por el resto de versiones de .NET Framework instaladas en el equipo. Para obtener información detallada acerca de la forma de configurar la ejecución simultánea, vea Ejecución simultánea.

Una aplicación compilada mediante una versión de .NET Framework se puede ejecutar en otra versión distinta de .NET Framework. No obstante, se recomienda compilar una versión de la aplicación por cada versión de .NET Framework instalada y se recomienda también ejecutarlas por separado. En cualquier caso, debe tener en cuenta los cambios de ADO.NET según las distintas versiones, ya que pueden afectar a la compatibilidad con versiones posteriores o anteriores de la aplicación.

Compatibilidad con versiones posteriores y anteriores

La compatibilidad con versiones posteriores significa que una aplicación se puede compilar y ejecutar tanto en versiones posteriores como en versiones anteriores de .NET Framework. El código de ADO.NET, escrito para la versión 1.1 de .NET Framework, es compatible con las versiones posteriores, siempre y cuando no se utilicen las nuevas características incluidas en la versión 1.1 de .NET Framework. Las nuevas características agregadas a ADO.NET en la versión 1.1 de .NET Framework son las siguientes:

El método EnlistDistributedTransaction de Connection. Vea Inscribir en una transacción distribuida.
La propiedad HasRows del DataReader. Vea Recuperar datos mediante DataReader.
La incorporación del proveedor de datos de .NET Framework para ODBC. Vea System.Data.Odbc (Espacio de nombres).
La incorporación del proveedor de datos de .NET Framework para Oracle. Vea System.Data.OracleClient (Espacio de nombres).

La compatibilidad con versiones anteriores significa que una aplicación se ha compilado para una versión anterior de .NET Framework, pero se ejecuta también en versiones posteriores de .NET Framework, sin que su funcionalidad se vea afectada.

Aunque los componentes de ADO.NET en la versión 1.1 de .NET Framework están diseñados para ser compatibles tanto con versiones posteriores como con versiones anteriores (a excepción de las nuevas características), debe tener en cuenta varias cuestiones que afectan a la compatibilidad con las versiones posteriores o anteriores de una aplicación.

A continuación, se describen algunos problemas de la ejecución simultánea que pueden afectar a la compatibilidad con las versiones anteriores o posteriores del código de ADO.NET. Las cuestiones que se explican en este tema son las siguientes:

Proveedor de datos de .NET Framework para ODBC
Proveedor de datos de .NET Framework para Oracle
Seguridad de acceso a código
DataSet
Ejecución de SqlCommand
Versión de MDAC

Proveedor de datos de .NET Framework para ODBC

El proveedor de datos de .NET Framework para ODBC (System.Data.Odbc) se incluye como parte de .NET Framework a partir de la versión 1.1. Sin embargo, el proveedor de datos de ODBC no se incluye en la versión 1.0 de .NET Framework. El proveedor de datos de ODBC está disponible para los programadores de .NET Framework versión 1.0 mediante descarga desde el Web en la dirección https://msdn.microsoft.com/downloads. El espacio de nombres del proveedor de datos de .NET Framework para ODBC descargado es Microsoft.Data.Odbc.

Si ha programado una aplicación para la versión 1.0 de .NET Framework que utiliza el proveedor de datos de ODBC para conectarse al origen de datos y desea ejecutar dicha aplicación en la versión 1.1 de .NET Framework, es necesario que actualice el espacio de nombres del proveedor de datos de ODBC a System.Data.Odbc. A continuación, debe volver a realizar la compilación para la versión 1.1 de .NET Framework.

Si ha programado una aplicación para la versión 1.1 de .NET Framework que utiliza el proveedor de datos de ODBC para conectarse al origen de datos y desea ejecutar esta aplicación en la versión 1.0 de .NET Framework, es necesario descargue el proveedor de datos de ODBC y que lo instale en el sistema .NET Framework versión 1.0. A continuación, deberá actualizar el espacio de nombres para el proveedor de datos de ODBC a Microsoft.Data.Odbc y deberá volver a realizar la compilación para la versión 1.0 de .NET Framework.

Proveedor de datos de .NET Framework para Oracle

El proveedor de datos de .NET Framework para Oracle (System.Data.OracleClient) se incluye como parte de .NET Framework a partir de la versión 1.1. Sin embargo, el proveedor de datos no se incluye en la versión 1.0 de .NET Framework. Este proveedor de datos está disponible para los programadores de .NET Framework versión 1.0 mediante descarga desde el Web en la dirección https://msdn.microsoft.com/downloads.

Si ha programado una aplicación para la versión 1.1 de .NET Framework que utiliza el proveedor de datos para conectarse al origen de datos y desea ejecutar esta aplicación en la versión 1.0 de .NET Framework, es necesario descargue el proveedor de datos y que lo instale en el sistema .NET Framework versión 1.0.

Seguridad de acceso a código

En la versión 1.0 de .NET Framework, se requiere que los proveedores de datos de .NET Framework (System.Data.SqlClient, System.Data.OleDb) se ejecuten con un permiso FullTrust. Si se intentan utilizar los proveedores de datos de .NET Framework de la versión 1.0 de .NET Framework en una zona con un permiso inferior a FullTrust, se produce una excepción SecurityException.

Ahora, en la versión 1.1 de .NET Framework, el proveedor de datos de .NET Framework para SQL Server se puede utilizar en zonas que no sean de plena confianza. Los proveedores de datos de OLE DB y ODBC aún requieren un permiso FullTrust.

Se ha agregado una característica de seguridad para los proveedores de datos de .NET Framework a la versión 1.1 de .NET Framework; esta nueva característica permite restringir las cadenas de conexión que se pueden utilizar en una zona de seguridad en particular. Es posible también deshabilitar el uso de contraseñas en blanco para una zona de seguridad determinada. Para obtener más información, vea Seguridad de acceso a código y ADO.NET.

Como cada una de las instalaciones de .NET Framework tiene un archivo Security.config independiente (vea Archivos de configuración de seguridad), no existen problemas de compatibilidad con versiones posteriores o anteriores en lo que se refiere a la configuración de seguridad. Sin embargo, si su aplicación depende de las capacidades de seguridad adicionales de ADO.NET incluidas en la versión 1.1 de .NET Framework, no podrá distribuir la aplicación a un sistema .NET Framework versión 1.0.

DataSet

El DataSet de la versión 1.1 de .NET Framework contiene diversos errores corregidos que modifican el comportamiento del DataSet con respecto a la versión 1.0 de .NET Framework. Si el código depende del comportamiento en la versión 1.0, pueden presentarse problemas de compatibilidad con versiones anteriores. Estos son los cambios que se han realizado en el comportamiento del DataSet.

Los valores de columna predeterminados establecidos como cadenas vacías en el esquema del lenguaje de definición de esquemas XML (XSD) para un DataSet ya no se interpretan como null.
Las restricciones se validan después de modificar la propiedad Locale.
En la versión 1.1, si el esquema del DataSet contiene elementos con el mismo nombre, pero con tipos distintos en el mismo espacio de nombres, se inicia una excepción al intentar leer el esquema en un DataSet o cuando el DataSet realiza una interacción remota con un cliente de la versión 1.1. Supongamos que tiene dos tablas relacionadas y una columna de la tabla primaria tiene el mismo nombre que la tabla secundaria; si la propiedad Nested de DataRelation es true, se inicia una excepción ya que la tabla secundaria se coloca en el mismo espacio de nombres que la tabla primaria en el esquema XML del DataSet. Si la propiedad Nested de DataRelation es false, no se inicia ninguna excepción.
Se presenta un caso especial en la interacción remota con un DataSet cuando se establece la propiedad AllowDBNull de una columna en false y la propiedad ColumnMapping de dicha columna en MappingType.Attribute. En el caso de un DataSet en el que se realiza una interacción remota desde un sistema .NET Framework versión 1.0, cuando el cliente intenta cargar el DataSet remoto, se produce una excepción. En el caso de un DataSet en el que se realiza una interacción remota desde un sistema .NET Framework versión 1.1, no se produce ninguna excepción. Sin embargo, los sistemas de la versión 1.0 no pueden leer el valor DefaultValue de la columna. En el caso de los sistemas de la versión 1.0, el valor DefaultValue de la columna es String.Empty.
Si el esquema XML del DataSet incluye un atributo targetNamespace, es posible que no se lean los datos y que se produzcan excepciones al llamar a ReadXml para cargar el DataSet con XML que contenga elementos que no disponen de un espacio de nombres completo. En este caso, para leer los elementos incompletos, establezca elementFormDefault en "completo" en el esquema XML. Por ejemplo:
```
<xsd:schema id="MyDataSet" 
  elementFormDefault="qualified"
  targetNamespace="http://www.tempuri.org/MyDataSet.xsd" 
  xmlns="http://www.tempuri.org/MyDataSet.xsd" 
  xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
  xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
</xsd:schema>
```

Ejecución de SqlCommand

Se ha producido un cambio de comportamiento en el modo en que SqlCommand.ExecuteReader ejecuta los comandos en el origen de datos en la versión 1.1 de .NET Framework.

En la versión 1.0 de .NET Framework, SqlCommand.ExecuteReader ejecuta todos los comandos en el contexto del procedimiento almacenado sp_executesql. Como resultado, los comandos que influyen en el estado de la conexión (Activar NOCOUNT, por ejemplo) sólo se aplican a la ejecución del comando actual. Mientras la conexión permanece abierta, los comandos que se ejecutan posteriormente no modifican el estado de la conexión.

En la versión 1.1 de .NET Framework, SqlCommand.ExecuteReader sólo ejecuta un comando en el contexto del procedimiento almacenado sp_executesql si dicho comando contiene parámetros, ya que de esta forma mejora el rendimiento. Como consecuencia, los comandos que influyen en el estado de la conexión, que se incluyen en un comando sin parámetros, modifican el estado de la conexión de todos los comandos posteriores que se ejecuten mientras la conexión esté abierta.

Tomemos como ejemplo el siguiente lote de comandos, que se ejecuta en una llamada a SqlCommand.ExecuteReader.

SET NOCOUNT ON;
SELECT * FROM Customers;

En la versión 1.1 de .NET Framework, NOCOUNT permanecerá en ON para los comandos que se ejecuten posteriormente, mientras la conexión esté abierta. En el caso de la versión 1.0 de .NET Framework, NOCOUNT sólo permanece en ON para la ejecución de comandos actual.

Este cambio puede afectar tanto a la compatibilidad con versiones posteriores como a la compatibilidad con versiones anteriores de la aplicación si depende del comportamiento de SqlCommand.ExecuteReader para cualquiera de las versiones de .NET Framework.

Para las aplicaciones que se ejecutan en versiones anteriores y posteriores de .NET Framework, puede escribir el código para asegurarse de que el comportamiento sea el mismo independientemente de la versión que se esté ejecutando. Si desea asegurarse de que un comando modifica el estado de la conexión para todos los comandos que se ejecuten posteriormente, es recomendable que ejecute el comando utilizando SqlCommand.ExecuteNonQuery. Si desea asegurarse de que un comando no modifica el estado de la conexión para todos los comandos que se ejecuten posteriormente, es recomendable que incluya los comandos para restablecer el estado de la conexión en el comando. Por ejemplo:

SET NOCOUNT ON;
SELECT * FROM Customers;
SET NOCOUNT OFF;

Versión de MDAC

Los proveedores de datos de todas las versiones de .NET Framework requieren la instalación de MDAC 2.6 o posterior. Si bien esto no presenta problemas de ejecución simultánea, es importante tener en cuenta que, en la actualidad, MDAC no admite la ejecución simultánea. Por lo tanto, es importante comprobar que la aplicación seguirá funcionando correctamente con la nueva versión antes de actualizar los componentes de MDAC de la instalación.

Vea también

Información general acerca de ADO.NET | Arquitectura de ADO.NET | Utilizar proveedores de datos de .NET Framework para obtener acceso a datos

Last updated on 2008-04-11

Compartir a través de