Archive

Posts Tagged ‘C#’

[C#] Utiliser des tables temporaires avec Entity Framework

Ça fait maintenant quelques temps que je travaille avec Entity Framework et, s’il est très bien, il pêche majoritairement sur un point (dans le cadre de mon usage) : le traitement du volume.
Donc, dans ce billet, je vais présenter une petite solution montrant ce que j’ai fait pour combler ce problème.

Lire la suite…

Catégories :.Net, C#, Développement

Entity Framework et NULL

Décidément, y a des fois où j’ai pas de bol 🙂

Le scénario est assez simple : j’ai une méthode qui doit aller chercher une ou plusieurs entrées en base de données.
Le critère de recherche est sur un champ nullable.

(Note : c’est la même table que là : ADO.Net Entity Data Model et champs avec valeur par défaut)

Du genre :

public IEnumerable<MATABLE> GetValue(SAMPLESEntities context, string search)
{
    return context.MATABLE.Where(m => m.COLONNE2 == search);
}

Jusque là, rien de bien gênant.
Mais…est si la variable search est nulle ???

Voici la requête exécutée par EF dans le cas de la méthode ci-dessus :

exec sp_executesql N'SELECT 
   [Extent1].[PK] AS [PK], 
   [Extent1].[COLONNE1] AS [COLONNE1], 
   [Extent1].[COLONNE2] AS [COLONNE2], 
   [Extent1].[COLONNE3] AS [COLONNE3], 
   [Extent1].[CREATION] AS [CREATION]
   FROM [dbo].[MATABLE] AS [Extent1]
   WHERE [Extent1].[COLONNE2] = @p__linq__0',
N'@p__linq__0 varchar(8000)',@p__linq__0=NULL

Et voici la requête exécutée si on fait

context.MATABLE.Where(m => m.COLONNE2 == null);
SELECT 
   [Extent1].[PK] AS [PK], 
   [Extent1].[COLONNE1] AS [COLONNE1], 
   [Extent1].[COLONNE2] AS [COLONNE2], 
   [Extent1].[COLONNE3] AS [COLONNE3], 
   [Extent1].[CREATION] AS [CREATION]
   FROM [dbo].[MATABLE] AS [Extent1]
   WHERE [Extent1].[COLONNE2] IS NULL

La différence est notable, non ?
Pourquoi ?
Parce que !
…NULL n’est pas une valeur ! (et c’est pas nouveau ^^)

Il faut donc gérer dans le code C# la possibilité que la variable soit nulle.
Voici un billet bien foutu qui en décrit : NULL value handling in Entity Framework.

A noter, tout de même que l’article parle d’un context (SAMPLESEntities, dans l’exemple) héritant de DbContext. Si le votre hérite de ObjectContext, eh bah c’est mort.
Dans ce cas, il faudra tester la valeur à la main pour réaliser le conditionnement qui va bien.

Un truc du genre :

return string.IsNullOrEmpty(search)
    ? context.MATABLE.Where(m => m.COLONNE2 == null)
    : context.MATABLE.Where(m => m.COLONNE2 == search);
Catégories :.Net, C#, Développement

ADO.Net Entity Data Model et champs avec valeur par défaut

Récemment, j’ai eu un problème lors de l’insertion avec Entity Framework.
Le cas est assez simple : je ne spécifiais pas de valeur sur une colonne non nullable mais ayant une contrainte de valeur par défaut.
Et là, bam : « Impossible d’insérer la valeur NULL dans la colonne ‘[COLONNE]’, table ‘[BASE].[SCHEMA].[TABLE]’. Cette colonne n’accepte pas les valeurs NULL. Échec de INSERT. L’instruction a été arrêtée. »

Donc, ce billet va donner le cas de test et les solutions pour le gérer.

Lire la suite…

Catégories :.Net, C#, Développement

WiX

J’avais déjà parlé de WIX dans un billet : How to Start : WIX (ça peut être utile de le lire en premier, si vous ne connaissez pas WiX).
Je suis récemment revenu dessus pour créer un installeur « un peu » custom.

Au programme, donc :

  • Ajouter une icône au programme
  • Déployer des fichiers dans un sous-répertoires
  • Modifier un champ dans l’App.Config depuis l’installeur
  • Paramétrer la chaîne de connexion EF depuis l’installeur
  • Déboguer les Custom Actions
  • Passer des paramètres à l’installeur

Lire la suite…

Catégories :.Net, C#, WIX

[C# EF5] Requêtes Compilées

Ce billet fait suite à la petite série sur l’optimisation.
La situation est expliquée ici Optimisations C#, Entity Framework et Sql, donc je n’y reviendrais pas.

Ce billet va traiter d’une optimisation au niveau de LINQ : les requêtes compilées.

Le scénario :
J’ai une liste de N éléments, peut être 1, mais dans mon test de charge : 50.000.
Chaque élément est un objet contenant une agrégation logique des plusieurs autres objets que je peuple au fil des traitements.
Je dois peupler l’un d’eux à partir d’une table très grosse (la même table qu’avant, avec ces 75 millions d’entrées).

Lire la suite…

Catégories :.Net, C#, Développement

Optimisations C#, Entity Framework et Sql

Ça fait un petit moment maintenant que je fais des tests de charges.
Le code n’était pas toujours optimisé au mieux, ce qui m’a posé divers problèmes : timeouts sur la base de données, explosions des requêtes Linq to Entities, Entity Framework à la ramasse…

Bref, j’ai du modifier pas mal de choses pour arriver à un résultat plus acceptable.
Dans ce billet, ce sera juste la situation générale et les liens vers les billets détaillant la résolution.

Dans un premier temps, voici grosso modo l’algorithme :

  1. Préparation du traitement
    1. Récupération des informations pour paramétrage
    2. Récupération de données de références pour les modifier et créer de nouvelles données
    3. Création en base des données de test
    4. Création d’un fichier en entrée
  2. Lancement du traitement
    1. Lecture du fichier
    2. Conversion du fichier en objets
    3. Validation des lignes
    4. Récupération des données complémentaires (connecté à la BDD)
    5. Création des nouvelles entrées (déconnecté)
    6. Insertion en base de données (transactionnel)
  3. Validation du test
    1. Récupération des lignes générées en BDD
    2. Validation des lignes

Si pour un test sur 500 lignes (quelques secondes), ça passe pas trop mal, sur 50.000, c’était pas franchement le même succès (près de 10 minutes).

Les points majeurs d’achoppement se situaient sur la récupération de la donnée de référence (point 1.2); insertion en base des données de test (les 50.000 lignes, point 1.3); récupération des données complémentaires (point 2.4) et enfin l’insertion en base de données des lignes traitées (2.6).

Pour les points 1.3 et 2.6, c’est le Bulk Insert qui m’a sauvé.
J’en ai parlé ici : [C#] Entity Framework et Bulk Insert.

Pour le point 1.2, c’est du SQL avec le hint FORCESEEK : [C#-TSQL] FORCESEEK et Entity Framework.

Et enfin, pour le point 2.4, c’est les requêtes compilées d’EF 5 : [C# EF5] Requêtes Compilées.

Au final, 50.000 lignes sont maintenant traitées en moins de 3 minutes (le scénario complet).
C’est plutôt pas mal, d’autant que le DBA m’a demandé de mettre quelques temporisation pour laisser respirer un peu la base de données (et permettre aux autres applications de tourner) ^^

Catégories :.Net, Développement, Sql Server

[C#-TSQL] FORCESEEK et Entity Framework

Ce billet fait suite à la petite série sur l’optimisation.
La situation est expliquée ici Optimisations C#, Entity Framework et Sql, donc je n’y reviendrais pas.

Ce présent billet va traiter du hint FORCESEEK sur SQL Server et comment l’utiliser avec Entity Framework.

Lire la suite…

Catégories :.Net, C#, Développement