none
LINQ : Mettre à jour une clé étrangère... RRS feed

  • Question

  • Bonjour,

    J'ai deux tables TPiece (PIE_ID INT, PIE_NOM VARCHAR(50), TPI_TYPE INT) et TTypePiece (TPI_TYPE INT, TPI_LIB VARCHAR(50)). Le lien entre les deux tables se fait par TPI_INT. Le tout est mappé avec LINQ To SQL.

    J'ai une procédure qui va affecter le type d'une pièce en fonction du libellé de son type, qui ressemble à ça :

    void AssignTypePiece(string ATypeLib)
    
    {
    
     TTypePiece lTypePiece;
    
    
    
     if (ATypeLib != null) 
    
     {
    
     dbDataContext lDC = new dbDataContext();
    
     lTypePiece = lDC.TTypePiece.SingleOrDefault(elTypePiece => elTypePiece.TypePieceLib == ATypeLib);
    
     
    
     if (lTypePiece == null)
    
     {
    
      lTypePiece = new TTypePiece();
    
      lTypePiece.TypePieceLib = ATypeLib;
    
      _CurrentPiece.TTypePiece = lTypePiece;
    
      lDB.TTypePiece.InsertOnSubmit(lTypePiece);
    
     }
    
     else
    
     {
    
      _CurrentPiece.TTypePiece = lTypePiece;
    
     }
    
     }
    
     else
    
     {
    
     _CurrentPiece.TTypePiece = null;
    
     }
    
    }
    
    

    Quand le type n'existe pas, pas de problème, le SubmitChanges génère bien un INSERT dans la table TTypePiece et un UPDATE dans la table TPiece.

    Mais quand le type existe, là où on met à jour uniquement le lien de la pièce vers son type, le SubmitChanges génère encore un INSERT dans TTypePiece, ce qui provoque évidement une violation de clé. Je m'attends à voir passer un seul UDPATE dans la table TPiece sur le champ TPI_TYPE...

    Qu'ai je mal fait ? :)

    Je vous remercie beaucoup

     

     

     

    jeudi 6 mai 2010 09:43

Réponses

  • Bonjour,

    A chaque fois vous appellez InsertOnSubmit() pour indiquer à Linq To SQL de générer une commande INSERT sur l'objet associé. Dans le cas de modification, il faut juste faire un SubmitChanges() sans faire un InsertOnSubmit().

    Cordialement


    Gilles TOURREAU - MVP C# - Architecte .NET/Consultant/Formateur
    jeudi 6 mai 2010 11:20
    Modérateur
  • Bonjour Gilles,

    Le problème se trouve justement là.

    Quand je passe dans le bloc de code qui fait l'InsertOnSubmit, tout se passe bien. Mais quand je passe dans le bloc qui ne le fait pas, qui revient à :

    void AssignTypePiece(string ATypeLib)
    {
     TTypePiece lTypePiece;
     dbDataContext lDC = new dbDataContext();
     lTypePiece = lDC.TTypePiece.SingleOrDefault(elTypePiece => elTypePiece.TypePieceLib == ATypeLib);
     _CurrentPiece.TTypePiece = lTypePiece;
    }

    ... là aussi, cela génère un ordre INSERT dans TTypePiece lors du SubmitChanges alors que je devrais vois passer un UDPATE sur TPiece... ?

    jeudi 6 mai 2010 12:26

Toutes les réponses

  • Bonjour,

    A chaque fois vous appellez InsertOnSubmit() pour indiquer à Linq To SQL de générer une commande INSERT sur l'objet associé. Dans le cas de modification, il faut juste faire un SubmitChanges() sans faire un InsertOnSubmit().

    Cordialement


    Gilles TOURREAU - MVP C# - Architecte .NET/Consultant/Formateur
    jeudi 6 mai 2010 11:20
    Modérateur
  • Bonjour Gilles,

    Le problème se trouve justement là.

    Quand je passe dans le bloc de code qui fait l'InsertOnSubmit, tout se passe bien. Mais quand je passe dans le bloc qui ne le fait pas, qui revient à :

    void AssignTypePiece(string ATypeLib)
    {
     TTypePiece lTypePiece;
     dbDataContext lDC = new dbDataContext();
     lTypePiece = lDC.TTypePiece.SingleOrDefault(elTypePiece => elTypePiece.TypePieceLib == ATypeLib);
     _CurrentPiece.TTypePiece = lTypePiece;
    }

    ... là aussi, cela génère un ordre INSERT dans TTypePiece lors du SubmitChanges alors que je devrais vois passer un UDPATE sur TPiece... ?

    jeudi 6 mai 2010 12:26
  • Bonsoir Messieurs,

    C'est bon j'ai trouvé : je n'utilisais pas le même DataContext pour les opérations de chargement des pièces et pour mettre à jour le type de pièces.

    Je vous remercie pour votre aide ! :)

    David.

    jeudi 6 mai 2010 17:35