Forum Aux Questions (FAQ)

Vérifiez que votre chaîne de connexion est correcte et que votre instance SQL Server s’exécute. Notez également que LINQ to SQL requiert l’activation du protocole Named Pipes. Pour plus d’informations, consultez Apprentissage par les procédures pas à pas.

Assurez-vous que vous appelez SubmitChanges pour enregistrer les résultats dans la base de données.

Une connexion reste généralement ouverte jusqu'à ce que vous utilisiez les résultats de la requête. Si vous prévoyez que le traitement de tous les résultats risque de prendre du temps et que vous n'êtes pas opposé à la mise en cache des résultats, appliquez ToList à la requête. Dans les scénarios courants où chaque objet est traité une seule fois, le modèle de diffusion en continu est supérieur à la fois dans DataReader et LINQ to SQL.

Les détails exacts d'utilisation de la connexion dépendent des éléments suivants :

• l'état de la connexion si le DataContext est généré avec un objet de connexion ;

• les paramètres de chaîne de connexion (par exemple, activation de MARS (Multiple Active Result Sets)). Pour plus d’informations, consultez MARS (Multiple Active Result Sets).

Bien que LINQ to SQL ne comporte pas de commandes de mise à jour reposant sur un jeu, vous pouvez utiliser l’une des techniques suivantes pour effectuer une mise à jour sans exécuter de requête préalable :

• Utilisez ExecuteCommand pour envoyer le code SQL.

• Créez une nouvelle instance de l'objet et initialisez toutes les valeurs actuelles (champs) qui affectent la mise à jour. Puis attachez l'objet au DataContext à l'aide de Attach et modifiez le champ que vous souhaitez changer.

LINQ to SQL fournit plusieurs outils permettant d’inspecter le code SQL qu’il génère. L'un des plus importants est Log. Pour plus d’informations, consultez Prise en charge du débogage.

LINQ to SQL fournit deux manières de retourner des valeurs générées par la base de données au moyen de procédures stockées :

• en nommant le résultat de sortie ;

• en spécifiant explicitement un paramètre de sortie.

Un exemple de sortie incorrecte est fourni ci-dessous. LINQ to SQL ne pouvant pas mapper les résultats, il retourne toujours 0 :

create procedure proc2

as

begin

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

end

Un exemple de sortie correcte à l'aide d'un paramètre de sortie est fourni ci-dessous :

create procedure proc2

@result int OUTPUT

as

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

go

Un exemple de sortie correcte à l'aide du nommage du résultat de sortie est fourni ci-dessous :

create procedure proc2

as

begin

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

end

Pour plus d’informations, consultez Personnalisation d’opérations à l’aide de procédures stockées.

La génération de code dans LINQ to SQL prend en charge la sérialisation DataContractSerializer. Elle ne prend pas en charge XmlSerializer ni BinaryFormatter. Pour plus d’informations, consultez Sérialisation.

Attribuez aux propriétés Context Namespace and Entity Namespace du Concepteur Objet Relationnel une valeur distincte pour chaque fichier DBML. Cette approche permet d'éliminer la collision de nom et d'espace de noms.

LINQ to SQL gère automatiquement cette situation pour les colonnes identity (incrémentation automatique), rowguidcol (GUID généré par la base de données) et timestamp. Dans les autres cas, vous devez définir manuellement les propriétés IsDbGenerated=true et AutoSync=Always/OnInsert/OnUpdate.

Oui. La première n'est pas remplacée, comme dans l'exemple suivant :

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);

Contrairement au runtime LINQ to SQL, le Concepteur Objet Relationnel ne prend pas en charge SQL Server Compact 3.5. Dans ce cas, vous devez créer vos propres classes d'entité et ajouter les attributs appropriés.

Il ne suffit pas de créer la relation. Vous devez fournir des informations telles que la colonne du discriminateur, la valeur du discriminateur de la classe de base et la valeur du discriminateur de la classe dérivée.

Aucun modèle de fournisseur public n'est disponible. Actuellement, LINQ to SQL prend uniquement en charge SQL Server et SQL Server Compact 3.5.

L'injection de code SQL est un risque significatif pour les requêtes SQL traditionnelles formées par la concaténation de l'entrée d'utilisateur. LINQ to SQL évite cette injection en utilisant SqlParameter dans les requêtes. L'entrée d'utilisateur est transformée en valeurs de paramètre. Cette technique empêche l'utilisation de commandes malveillantes à partir de l'entrée d'utilisateur.

Effectuez la procédure suivante pour ce scénario avancé :

1. Dans le fichier .dbml, modifiez la propriété en changeant l'indicateur IsReadOnly en True.

2. Ajoutez une classe partielle. Créez un constructeur avec des paramètres pour les membres en lecture seule.

3. Vérifiez la valeur par défaut de UpdateCheck (Never) pour déterminer si elle convient pour votre application.

   Attention

   Si vous utilisez le Concepteur Objet Relationnel dans Visual Studio, vos modifications peuvent être remplacées.

Oui, l’assembly System.Data.Linq.dll figure parmi ces assemblys .NET Framework marqués par l’attribut AllowPartiallyTrustedCallersAttribute. Sans ce marquage, les assemblys contenus dans .NET Framework sont uniquement conçus pour être utilisés par du code d’un niveau de confiance suffisant.

Le scénario principal dans LINQ to SQL pour l’autorisation des appelants d’un niveau de confiance partiel consiste à permettre l’accès de l’assembly LINQ to SQL à partir des applications Web, où la configuration de la confiance est Moyenne.

Vous pouvez créer une vue dans une base de données et mapper l'entité à la vue. LINQ to SQL génère pour les vues le même SQL que pour les tables.

N'essayez pas de réutiliser des instances de DataContext. Chaque DataContext gère l'état (y compris un cache d'identité) d'une session de modification/requête particulière. Pour obtenir des nouvelles instances basées sur l'état actuel de la base de données, utilisez un nouveau DataContext.

Vous pouvez néanmoins utiliser le pool de connexions ADO.NET sous-jacent. Pour plus d’informations, consultez Regroupement de connexions SQL Server (ADO.NET).

Ce comportement est normal. LINQ to SQL continue à retourner les mêmes instances/valeurs que vous avez vues dans la première instance. Lorsque vous effectuez des mises à jour, vous utilisez l'accès concurrentiel optimiste. Les données d'origine sont utilisées pour effectuer la comparaison avec l'état actuel de la base de données afin de vérifier qu'il n'a en fait pas été modifié. S'il a été modifié, un conflit se produit et votre application doit le résoudre. L'une des options de votre application consiste à réinitialiser l'état d'origine à l'état actuel de la base de données et à retenter la mise à jour. Pour plus d’informations, consultez Procédure : Gérer les conflits des modifications.

Vous pouvez également attribuer à ObjectTrackingEnabled la valeur false, ce qui désactive la mise en cache et le suivi des modifications. Vous pouvez ensuite extraire les valeurs les plus récentes chaque fois que vous exécutez une requête.

Le mode lecture seule désactive la capacité du contexte à suivre les modifications.

Voir aussi

• Référence
• Dépannage
• Sécurité dans LINQ to SQL