Bon, alors pour ce qui est de corriger les champs clefs, =E7a y est, en=20
montant une usine =E0 gaz j'ai pu faire =E7a via une connexion oledb en f=
in=20
de proc=E9dure, =E7a marche aux petits oignons. La connexion en question =
n'est ouverte que sur demande, si l'utilisateur veut modifier des champs =
clefs.
Maintenant, il reste =E0 modifier les autres champs. J'ai s=FBrement d=FB=
=20
red=E9finir des choses en route, le DataSet, la source du DataGridView,=20
toujours est-il que maintenant les modifs faites dans le DataGridView ne =
sont plus sauvegard=E9es.
A la sortie du formulaire j'affiche le champ du dataset, donc comme =E7a =
je v=E9rifie que le dataset a bien =E9t=E9 modifi=E9 tel que demand=E9 pa=
r=20
l'utilisateur, mais lorsque je recharge le formulaire je retrouve les=20
anciennes valeurs, donc les nouvelles n'ont pas =E9t=E9 sauvegard=E9es da=
ns la=20
base.
La requ=EAte UPDATE me surprend, j'en saisis une autre dans le code du=20
dataset, et l=E0 =E0 la sortie je m'aper=E7ois que le dataset n'est pas=20
modifi=E9, donc, finalement, la requ=EAte initiale n'=E9tait peut-=EAtre =
pas si=20
mauvaise que =E7a.
Bon, j'ai la solution de faire appel =E0 mon usine =E0 gaz pour sauvegard=
er=20
tous les champs, =E7a devrait finir par fonctionner, mais j'imagine qu'il=
=20
doit y avoir plus =E9l=E9gant.
Cette fois le formulaire principal est juste un menu, qui n'appelle pas=20
de donn=E9es, donc je pense avoir r=E9gl=E9 ce conflit.
Bon, on va laisser mijoter un peu.
Si quelqu'un a une d=E9marche carr=E9e pour modifier une table Access ave=
c=20
un DataGridView ...
A titre de curiosit=E9, voil=E0 l'essentiel de l'usine =E0 gaz. Il y a au=
ssi=20
un tableau d'objets dr[] d=E9clar=E9 au niveau module et initialis=E9 =E0=
new=20
dans le Form_Load.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Gloops
Bonjour,
J'ai écrit une mini-usine à gaz dans dataGridView1_CellEndEdit, avec exécution à chaque fois.
Cette formule est la plus lente puisqu'elle requiert un appel à la base à chaque modification de cellule, mais elle est plus facile à débog uer puisqu'on sait dans quels cas se pose un problème d'exécution de la requête, le code de la requête et l'exception levée.
Au vu des résultats, la piste à suivre semble être qu'il manquait l a gestion des valeurs nulles. J'ai bien détecté un problème à ce ni veau car un des paramètres indiquait des valeurs nulles refusées alors que je n'avais pas conscience qu'elles le soient dans la base, mais même en mettant quelque chose dans le champ ça ne passait pas. Il reste donc peut-être autre chose. Les paramètres sont créés par défaut ave c taille 0, je ne suis pas très certain que ce soit approprié. Au passage j'en ai profité pour ajouter la gestion des chaînes de caractères comportant une apostrophe (caractère encadrant les chaîn es de caractères), bien que le problème ne se posait pas avec les exemples essayés au préalable.
Quand on ne met rien dans une cellule, on reçoit une valeur nulle en retour. Je m'attendais à une chaîne vide, et en toute rigueur il devr ait y avoir moyen de proposer les deux. Apparemment, si on veut proposer les deux à l'utilisateur il faut réfléchir à une implémentation -pe ut-être lui proposer le choix avec une boîte de dialogue, mais dans ce cas j'imagine que l'édition de la requête dans une procédure événem entielle est la bonne formule.
Si quelqu'un veut se lancer dans l'approfondissement de cette question pour pouvoir faire les modifications dans la base Access avec une requête de modification fournie dans le DataSet, je peux lui refiler ce que j'ai fait histoire de gagner du temps, il faut dire qu'avec l'exécution champ par champ on voit largement plus clair, avec la requête du DataSet tout ce qu'on voit comme erreur est que la valeur n'est pas sauvegardée. _____________________________________ Gloops a écrit, le 11/08/2009 14:53 :
Bonjour tout le monde,
Bon, alors pour ce qui est de corriger les champs clefs, ça y est, en montant une usine à gaz j'ai pu faire ça via une connexion oledb en fin de procédure, ça marche aux petits oignons. La connexion en questio n n'est ouverte que sur demande, si l'utilisateur veut modifier des champ s clefs.
Maintenant, il reste à modifier les autres champs. J'ai sûrement dû redéfinir des choses en route, le DataSet, la source du DataGridView, toujours est-il que maintenant les modifs faites dans le DataGridView n e sont plus sauvegardées.
A la sortie du formulaire j'affiche le champ du dataset, donc comme ç a je vérifie que le dataset a bien été modifié tel que demandé par l'utilisateur, mais lorsque je recharge le formulaire je retrouve les anciennes valeurs, donc les nouvelles n'ont pas été sauvegardées dans la base.
La requête UPDATE me surprend, j'en saisis une autre dans le code du dataset, et là à la sortie je m'aperçois que le dataset n'est pas modifié, donc, finalement, la requête initiale n'était peut-êtr e pas si mauvaise que ça.
Bon, j'ai la solution de faire appel à mon usine à gaz pour sauvega rder tous les champs, ça devrait finir par fonctionner, mais j'imagine qu' il doit y avoir plus élégant.
Cette fois le formulaire principal est juste un menu, qui n'appelle pas de données, donc je pense avoir réglé ce conflit.
Bon, on va laisser mijoter un peu. Si quelqu'un a une démarche carrée pour modifier une table Access a vec un DataGridView ...
A titre de curiosité, voilà l'essentiel de l'usine à gaz. Il y a aussi un tableau d'objets dr[] déclaré au niveau module et initialisé à new dans le Form_Load.
J'ai écrit une mini-usine à gaz dans dataGridView1_CellEndEdit, avec
exécution à chaque fois.
Cette formule est la plus lente puisqu'elle requiert un appel à la base
à chaque modification de cellule, mais elle est plus facile à débog uer
puisqu'on sait dans quels cas se pose un problème d'exécution de la
requête, le code de la requête et l'exception levée.
Au vu des résultats, la piste à suivre semble être qu'il manquait l a
gestion des valeurs nulles. J'ai bien détecté un problème à ce ni veau
car un des paramètres indiquait des valeurs nulles refusées alors que je
n'avais pas conscience qu'elles le soient dans la base, mais même en
mettant quelque chose dans le champ ça ne passait pas. Il reste donc
peut-être autre chose. Les paramètres sont créés par défaut ave c taille
0, je ne suis pas très certain que ce soit approprié.
Au passage j'en ai profité pour ajouter la gestion des chaînes de
caractères comportant une apostrophe (caractère encadrant les chaîn es de
caractères), bien que le problème ne se posait pas avec les exemples
essayés au préalable.
Quand on ne met rien dans une cellule, on reçoit une valeur nulle en
retour. Je m'attendais à une chaîne vide, et en toute rigueur il devr ait
y avoir moyen de proposer les deux. Apparemment, si on veut proposer les
deux à l'utilisateur il faut réfléchir à une implémentation -pe ut-être
lui proposer le choix avec une boîte de dialogue, mais dans ce cas
j'imagine que l'édition de la requête dans une procédure événem entielle
est la bonne formule.
Si quelqu'un veut se lancer dans l'approfondissement de cette question
pour pouvoir faire les modifications dans la base Access avec une
requête de modification fournie dans le DataSet, je peux lui refiler ce
que j'ai fait histoire de gagner du temps, il faut dire qu'avec
l'exécution champ par champ on voit largement plus clair, avec la
requête du DataSet tout ce qu'on voit comme erreur est que la valeur
n'est pas sauvegardée.
_____________________________________
Gloops a écrit, le 11/08/2009 14:53 :
Bonjour tout le monde,
Bon, alors pour ce qui est de corriger les champs clefs, ça y est, en
montant une usine à gaz j'ai pu faire ça via une connexion oledb en fin
de procédure, ça marche aux petits oignons. La connexion en questio n
n'est ouverte que sur demande, si l'utilisateur veut modifier des champ s
clefs.
Maintenant, il reste à modifier les autres champs. J'ai sûrement dû
redéfinir des choses en route, le DataSet, la source du DataGridView,
toujours est-il que maintenant les modifs faites dans le DataGridView n e
sont plus sauvegardées.
A la sortie du formulaire j'affiche le champ du dataset, donc comme ç a
je vérifie que le dataset a bien été modifié tel que demandé par
l'utilisateur, mais lorsque je recharge le formulaire je retrouve les
anciennes valeurs, donc les nouvelles n'ont pas été sauvegardées dans la
base.
La requête UPDATE me surprend, j'en saisis une autre dans le code du
dataset, et là à la sortie je m'aperçois que le dataset n'est pas
modifié, donc, finalement, la requête initiale n'était peut-êtr e pas si
mauvaise que ça.
Bon, j'ai la solution de faire appel à mon usine à gaz pour sauvega rder
tous les champs, ça devrait finir par fonctionner, mais j'imagine qu' il
doit y avoir plus élégant.
Cette fois le formulaire principal est juste un menu, qui n'appelle pas
de données, donc je pense avoir réglé ce conflit.
Bon, on va laisser mijoter un peu.
Si quelqu'un a une démarche carrée pour modifier une table Access a vec
un DataGridView ...
A titre de curiosité, voilà l'essentiel de l'usine à gaz. Il y a aussi
un tableau d'objets dr[] déclaré au niveau module et initialisé à new
dans le Form_Load.
J'ai écrit une mini-usine à gaz dans dataGridView1_CellEndEdit, avec exécution à chaque fois.
Cette formule est la plus lente puisqu'elle requiert un appel à la base à chaque modification de cellule, mais elle est plus facile à débog uer puisqu'on sait dans quels cas se pose un problème d'exécution de la requête, le code de la requête et l'exception levée.
Au vu des résultats, la piste à suivre semble être qu'il manquait l a gestion des valeurs nulles. J'ai bien détecté un problème à ce ni veau car un des paramètres indiquait des valeurs nulles refusées alors que je n'avais pas conscience qu'elles le soient dans la base, mais même en mettant quelque chose dans le champ ça ne passait pas. Il reste donc peut-être autre chose. Les paramètres sont créés par défaut ave c taille 0, je ne suis pas très certain que ce soit approprié. Au passage j'en ai profité pour ajouter la gestion des chaînes de caractères comportant une apostrophe (caractère encadrant les chaîn es de caractères), bien que le problème ne se posait pas avec les exemples essayés au préalable.
Quand on ne met rien dans une cellule, on reçoit une valeur nulle en retour. Je m'attendais à une chaîne vide, et en toute rigueur il devr ait y avoir moyen de proposer les deux. Apparemment, si on veut proposer les deux à l'utilisateur il faut réfléchir à une implémentation -pe ut-être lui proposer le choix avec une boîte de dialogue, mais dans ce cas j'imagine que l'édition de la requête dans une procédure événem entielle est la bonne formule.
Si quelqu'un veut se lancer dans l'approfondissement de cette question pour pouvoir faire les modifications dans la base Access avec une requête de modification fournie dans le DataSet, je peux lui refiler ce que j'ai fait histoire de gagner du temps, il faut dire qu'avec l'exécution champ par champ on voit largement plus clair, avec la requête du DataSet tout ce qu'on voit comme erreur est que la valeur n'est pas sauvegardée. _____________________________________ Gloops a écrit, le 11/08/2009 14:53 :
Bonjour tout le monde,
Bon, alors pour ce qui est de corriger les champs clefs, ça y est, en montant une usine à gaz j'ai pu faire ça via une connexion oledb en fin de procédure, ça marche aux petits oignons. La connexion en questio n n'est ouverte que sur demande, si l'utilisateur veut modifier des champ s clefs.
Maintenant, il reste à modifier les autres champs. J'ai sûrement dû redéfinir des choses en route, le DataSet, la source du DataGridView, toujours est-il que maintenant les modifs faites dans le DataGridView n e sont plus sauvegardées.
A la sortie du formulaire j'affiche le champ du dataset, donc comme ç a je vérifie que le dataset a bien été modifié tel que demandé par l'utilisateur, mais lorsque je recharge le formulaire je retrouve les anciennes valeurs, donc les nouvelles n'ont pas été sauvegardées dans la base.
La requête UPDATE me surprend, j'en saisis une autre dans le code du dataset, et là à la sortie je m'aperçois que le dataset n'est pas modifié, donc, finalement, la requête initiale n'était peut-êtr e pas si mauvaise que ça.
Bon, j'ai la solution de faire appel à mon usine à gaz pour sauvega rder tous les champs, ça devrait finir par fonctionner, mais j'imagine qu' il doit y avoir plus élégant.
Cette fois le formulaire principal est juste un menu, qui n'appelle pas de données, donc je pense avoir réglé ce conflit.
Bon, on va laisser mijoter un peu. Si quelqu'un a une démarche carrée pour modifier une table Access a vec un DataGridView ...
A titre de curiosité, voilà l'essentiel de l'usine à gaz. Il y a aussi un tableau d'objets dr[] déclaré au niveau module et initialisé à new dans le Form_Load.
