Preguntas más frecuentes

Asegúrate de que tu cadena de conexión es correcta y de que tu instancia de SQL server se está ejecutando. También ten en cuenta que LINQ to SQL requiere que el protocolo Canalizaciones con nombre esté habilitado. Para obtener más información, consulta Aprender con tutoriales.

Asegúrese de que llama a SubmitChanges para guardar los resultados en la base de datos.

Normalmente, una conexión permanece abierta hasta que se utilizan los resultados de la consulta. Si espera que los resultados tarden tiempo en procesarse, y no se opone a que se almacenen en memoria caché, aplique ToList a la consulta. En escenarios habituales donde cada objeto se procesa solo una vez, el modelo de transmisión por secuencias es superior tanto en DataReader como en LINQ to SQL.

Los detalles exactos de uso de la conexión dependen de lo siguiente:

• Estado de la conexión si el DataContext se construye con un objeto de conexión.

• Opciones de la cadena de conexión; por ejemplo, habilitar conjuntos de resultados activos múltiples (MARS). Para obtener más información, consulte Conjuntos de resultados activos múltiples (MARS).

Aunque LINQ to SQL no posee comandos de actualización basados en conjuntos, puede utilizar cualquiera de las técnicas siguientes para actualizar sin consultar primero:

• Utilice ExecuteCommand para enviar código SQL.

• Cree una nueva instancia del objeto e inicialice todos los valores (campos) actuales que afectan a la actualización. A continuación, adjunte el objeto al DataContext utilizando Attach y modifique el campo que desee cambiar.

LINQ to SQL proporciona varias herramientas para inspeccionar el código SQL que genera. Una de las más importantes es Log. Para más información, consulte Soporte técnico para la Depuración.

LINQ to SQL proporciona dos maneras de devolver los valores generados por la base de datos a través de procedimientos almacenados:

• Asignando un nombre al resultado de salida.

• Especificando explícitamente un parámetro de salida.

El siguiente es un ejemplo de resultado incorrecto. Dado que LINQ to SQL no puede asignar los resultados, siempre devuelve 0:

create procedure proc2

as

begin

select max(i) from t where name like 'hello'

end

El siguiente es un ejemplo de resultado correcto que utiliza un parámetro de salida:

create procedure proc2

@result int OUTPUT

as

select @result = MAX(i) from t where name like 'hello'

go

El siguiente es un ejemplo de resultado correcto que asigna un nombre al resultado de salida:

create procedure proc2

as

begin

select nax(i) AS MaxResult from t where name like 'hello'

end

Para obtener más información, consulta Personalizar operaciones utilizando procedimientos almacenados .

La generación de código en LINQ to SQL admite la serialización DataContractSerializer. No admite XmlSerializer o BinaryFormatter. Para obtener más información, vea Serialización.

Establece las propiedades Espacio de nombres del contexto y Espacio de nombres de la entidad de Object Relational Designer en un valor distinto para cada archivo DBML. Este enfoque elimina la colisión entre nombres o espacios de nombres.

LINQ to SQL administra automáticamente esta situación para la identidad (incremento automático) y rowguidcol (GUID generado por base de datos) y para las columnas con marca de tiempo. En otros casos, debería establecer manualmente las propiedades IsDbGenerated=true y AutoSync=Always/OnInsert/OnUpdate.

Sí. La primera no se sobrescribe, como se muestra en el ejemplo siguiente:

Dim dlo As New DataLoadOptions()
dlo.LoadWith(Of Order)(Function(o As Order) o.Customer)
dlo.LoadWith(Of Order)(Function(o As Order) o.OrderDetails)

DataLoadOptions dlo = new DataLoadOptions();
dlo.LoadWith<Order>(o => o.Customer);
dlo.LoadWith<Order>(o => o.OrderDetails);

El Object Relational Designer no admite SQL Server Compact 3.5, aunque el entorno de ejecución de LINQ to SQL sí. En esta situación, debe crear sus propias clases de entidad y agregar los atributos adecuados.

Crear una relación no es suficiente. Debe proporcionar información tal como la columna de discriminador, el valor de discriminador de la clase base y el valor de discriminador de la clase derivada.

No existe ningún modelo de proveedor público disponible. En este momento, LINQ to SQL solo admite SQL Server y SQL Server Compact 3.5.

La inyección de código SQL ha sido un riesgo significativo para las consultas SQL tradicionales formadas mediante concatenación de los datos proporcionados por el usuario. LINQ to SQL evita esa inyección de código mediante el uso de SqlParameter en las consultas. Los datos proporcionados por el usuario se convierten en valores de parámetro. Este enfoque impide que se utilicen comandos malintencionados en los datos proporcionados por el cliente.

Siga estos pasos para este escenario avanzado:

1. En el archivo .dbml, modifique la propiedad cambiando la marca IsReadOnly a True.

2. Agregue una clase parcial. Cree un constructor con parámetros para los miembros de solo lectura.

3. Revise el valor predeterminado de UpdateCheck (Never) para determinar si ése es el valor correcto para su aplicación.

   Precaución

   Si estás usando el Object Relational Designer en Visual Studio, tus cambios pueden sobrescribirse.

Sí, el ensamblado System.Data.Linq.dll se encuentra entre los ensamblados de .NET Framework marcados con el atributo AllowPartiallyTrustedCallersAttribute. Sin esta señal, los ensamblados incluidos en .NET Framework están destinados para su uso en código de plena confianza.

El principal escenario de LINQ to SQL para permitir llamadores que no son de plena confianza es habilitar el ensamblado de LINQ to SQL desde aplicaciones web, cuya configuración de confianza es Media.

Puede crear una vista en una base de datos y asignar la entidad a la vista. LINQ to SQL genera el mismo código SQL para vistas que para tablas.

No intente reutilizar instancias de DataContext. Cada DataContext mantiene el estado (incluida una caché de identidad) para una sesión de edición o consulta particular. Para obtener nuevas instancias según el estado actual de la base de datos, utilice un nuevo DataContext.

Puedes seguir utilizando agrupamiento de conexiones ADO.NET subyacente. Para obtener más información, vea Agrupación de conexiones de SQL Server (ADO.NET).

Este comportamiento es así por diseño. LINQ to SQL continúa devolviendo los mismos valores o instancias que aparecen en la primera instancia. Cuando se realizan actualizaciones, se utiliza simultaneidad optimista. Los datos originales se utilizan para realizar una comprobación contra el estado de la base de datos actual a fin de comprobar que, de hecho, permanecen sin modificar. Si han cambiado, se produce un conflicto, y su aplicación deberá resolverlo. Una opción para su aplicación es restablecer el estado original al estado actual de la base de datos e intentar de nuevo la actualización. Para obtener más información, vea Cómo: Administrar confictos de cambios.

También puede establecer ObjectTrackingEnabled como falso, lo cual desactiva el almacenamiento en memoria caché y el seguimiento de cambios. A continuación, puede recuperar los últimos valores cada vez que realiza una consulta.

El modo de solo lectura desactiva la capacidad del contexto de realizar seguimiento de cambios.

Consulte también

• Referencia
• Solución de problemas
• Seguridad de LINQ to SQL