Discussion :

[FRED.G]

Bonjour

J'ai généré un Dataset fortement typé à l'aide de l'assistant (basé sur une bdd Access).

J'essaie de comprendre le code généré dans le fichier monDataSet.Designer.vb en étudiant un exemple de Partial Public Class correspondant à l'un de mes DataAdapter (typé en "TableAdapter" si j'ai bien compris) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Partial Public Class tblAccessoiresFournisTableAdapter 

Or je n'arrive pas à saisir pourquoi la fonction Update de cette classe se contente de faire appel à celle de son objet OleDbDataAdapter. Objet déclaré au début de la classe comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
Private WithEvents _adapter As System.Data.OleDb.OleDbDataAdapter

Voici un exemple de la fonction Update implémentée dans la classe tblAccessoiresFournisTableAdapter :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
        <System.Diagnostics.DebuggerNonUserCodeAttribute(),  _
         System.ComponentModel.Design.HelpKeywordAttribute
("vs.data.TableAdapter")>  _
        Public Overloads Overridable Function Update(ByVal dataTable As
 EliteDataSet.tblAccessoiresFournisDataTable) As Integer
            Return Me.Adapter.Update(dataTable)
        End Function

Comment se fait le lien entre la mise à jour déclenchée par cette fonction et les procédures définissant les commandes de mises à jour spécifiques à la classes tblAccessoiresFournisTableAdapter ??

Je parle de procédures comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Private Sub InitAdapter()

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Public Overloads Overridable Function Delete

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Public Overloads Overridable Function Insert

Etc.

[bidou]

Il n'y a pas de lien entre les deux.

Dans le cas d'un appel update, tu fais une mise à jour du lot concerné (par exemple la table) en fonction de la valeur des marqueurs rowstate.
Dans le cas d'un appel Insert, tu passe les paramètres nécéssaires pour l'action sur une commande spécifique concernant un enregistrement.

[FRED.G]

Dans le cas d'un appel update, tu fais une mise à jour du lot concerné (par exemple la table) en fonction de la valeur des marqueurs rowstate.

Donc si je comprends bien, j'ai dans ma classe xxTableAdapter :

- Une fonction Delete et une fonction Insert que je peux appeler quand je veux pour un enregistrement donné.

D'ailleurs, au passage, si j'ai bien suivi ton cours, je peux modifier directement la fonction Delete afin de ne demander en paramètre que la/les valeur(s) de clés de l'enregistrement (idem pour le code de la sub InitAdapter)

- une fonction Update qui, elle, peut concerner plusieurs enregistrements et qui va se charger d'éxécuter les commandes de mise à jour (update / Delete / Insert) du OleDbDataAdapter (définies dans la sub InitAdapter).

Mais alors, si j'ai besoin d'ajouter du code spécifique à mes mises à jour, par exemple pour récupérer une valeur de clé dans la source de donnée avant ou après l'avoir mise à jour, j'ai éventuellement plusieurs endroits où je dois insérer mon code :

- directement dans les fonctions de la classe xxTableAdapter (ou alors à l'endroit duquel je les appelle)

- dans les événements OnrowUpdating / OnRowUpdated


C'est bien ça ?

[bidou]

Donc si je comprends bien, j'ai dans ma classe xxTableAdapter :

- Une fonction Delete et une fonction Insert que je peux appeler quand je veux pour un enregistrement donné.

D'ailleurs, au passage, si j'ai bien suivi ton cours, je peux modifier directement la fonction Delete afin de ne demander en paramètre que la/les valeur(s) de clés de l'enregistrement (idem pour le code de la sub InitAdapter)

C'est exactement ça, cependant il n'existera qu'une seule comande Delete qui utilisera la même générations de paramêtres pour tous les cas de concurrences. Il est parfois intéressant de générer un Delete2 pour d'autres cas

Mais alors, si j'ai besoin d'ajouter du code spécifique à mes mises à jour, par exemple pour récupérer une valeur de clé dans la source de donnée avant ou après l'avoir mise à jour, j'ai éventuellement plusieurs endroits où je dois insérer mon code :

- directement dans les fonctions de la classe xxTableAdapter (ou alors à l'endroit duquel je les appelle)

- dans les événements OnrowUpdating / OnRowUpdated


C'est bien ça ?

C'est exact mais pas nécéssairement suffisant. Parce qu'en fait cela dépend aussi de la capacité de ton SGBD à répondre à une requête d'interrogation postérieure à l'action. L'eternel problême du monde ADO, qu'il soit .Net ou non, réside dans cet échange de paramêtre d'entrée, paramêtre de retour et capacité de mappage de l'ensemble par ADO.
L'expérience prouve qu'il vaut mieux faire confiance à des procédures stockées bien écrites et à un code "adapté" qu'au comportement par défaut d'ADO.

[FRED.G]

Ok. Ben merci pour ces précisions, et le cours !

Dans mon cas, je travaille avec une base Access en local. J'ai bien noté la stratégie que tu proposes pour gérer les identifiants auto-incrémentés d'access (on retrouve cette soluce chez MS aussi).

Cependant, comme je t'ai vu écrire que la gestion des clé auto-incrémentée nous poussait à des manipuilations plus ou moins abominables, j'ai voulu m'en passer, même si, pour autant je n'ai pas su me trouver des clés "porteuses d'information"...

Donc j'ai pensé à calculer moi-même la valeur de mes clés au moment de l'insertion, en lisant via une commande scalaire la valeur de la dernière clé enregistrée dans la table de ma source, afin de mettre à jour mon dataset puis de lancer les commandes d'insertion (le tout sur la même connexion exclusive).

J'élimine ainsi les étapes qui consistent à merger mon dataset de départ avec le dataset de retour, puis éliminer les enregistrements dupliqués contenant les clés provisoires (les clés "négatives" dans ton exemple)...

[bidou]

Nous voila relancé dans l'éternel débat.
1) Contrairement à Fred Brouard, je ne suis pas sur que l'opposition systématique aux clés informationnelles soient fondées. Il existe des clés partiellement infomationneles telles que le numéro de sécurité sociale qui ont fait leurs preuves.

2) Il n'y a pas d'intérêt dans la logique d'un SGBD que les clés soit "consécutive", puisque cette notion n'existe pas pour un SGBD. Des éléments de type TimeStamp devrait être suffisant pour créer l'unicité, et la notion d'enregistrement précédent n'a pas véritablement de sens puisque celui ci peut être un jour amené à disparaitre.