Avec un DataGridView, je veux mettre =E0 jour une table Access.
Tant que je m'attaque =E0 un champ non clef, je peux dire que =E7a se pas=
se=20
plut=F4t bien, enfin apr=E8s avoir saisi la requ=EAte moi-m=EAme.
La clef est compos=E9e de quatre champs, entier, cha=EEne de caract=E8res=
,=20
date, entier.
Il s'est trouv=E9 qu'un enregistrement a =E9t=E9 cr=E9=E9 avec une erreur=
au=20
niveau de la date dans la clef. L'enregistrement a =E9t=E9 cr=E9=E9 avec =
la date=20
syst=E8me au moment de sa cr=E9ation, et pas de pot il a =E9t=E9 saisi av=
ec=20
retard. Cette cr=E9ation a =E9t=E9 faite en runtime Access, or comme je n=
e=20
dispose plus d'Access je ne peux corriger le code responsable de=20
l'erreur, de toute mani=E8re =E7a aurait =E9t=E9 hors sujet ici.
Le premier champ, entier, s'appelle num=E9ro de poste. Il se trouve qu'un=
=20
seul enregistrement porte le num=E9ro de poste sur lequel je veux corrige=
r=20
la date dans la clef, donc SQL peut tr=E8s bien s'en sortir.
Je me suis dit que =E7a pouvait =EAtre int=E9ressant de tenter cet exerci=
ce=20
avec le DataGridView, en n'oubliant pas de remettre celui-ci dans son=20
=E9tat normal apr=E8s.
J'ai bricol=E9 la requ=EAte Update pour que seul le num=E9ro de poste soi=
t=20
consid=E9r=E9 comme clef, et que les autres champs soient modifi=E9s par =
la=20
requ=EAte.
Premier essai, plantage (affichage de la page d'erreur du site web).
J'avais enlev=E9 l'attribut ReadOnly juste =E0 la colonne qui m'int=E9res=
sait,=20
et on m'a object=E9 une erreur de type. Donc, j'imagine que les champs se=
=20
sont d=E9cal=E9s d'autant de crans qu'il y avait de colonnes en ReadOnly =
=E0=20
mauvais escient.
J'ai enlev=E9 l'attribut ReadOnly =E0 toutes les colonnes sauf le num=E9r=
o de=20
poste. Cette fois, la modification de la date n'a pas provoqu=E9 de=20
plantage. Seul inconv=E9nient, apr=E8s la validation l'enregistrement se =
r=E9affiche avec la date qu'il avait avant la mise =E0 jour.
Il faut dire qu'Access a un moyen tr=E8s efficace pour rep=E9rer les=20
diff=E9rents param=E8tres, puisque dans la requ=EAte SQL ils sont repr=E9=
sent=E9s=20
par chacun un point d'interrogation.
=E7a va m=EAme plus loin, l'assistant Configure DataSource, dans sa fonct=
ion=20
Execute Query, propose une bo=EEte de dialogue avec autant de zones de=20
saisie que de param=E8tres, et un point d'interrogation devant chaque,=20
comme invite de saisie. Donc, sur la premi=E8re ligne, en face du point=20
d'interrogation on saisit le champ correspondant au point=20
d'interrogation, sur la deuxi=E8me ligne, en face du point=20
d'interrogation, on saisit le champ correspondant au point=20
d'interrogation, et ainsi de suite.
Est-ce envisageable de mettre un peu d'ordre dans ce bazar ?
Donner des noms aux param=E8tres pourrait aider, d=E9j=E0.
J'imaginerais bien aussi de d=E9signer l'enregistrement par son num=E9ro =
d'ordre, bon =E7a c'est facile avec une clef Num=E9roAuto, mais comme ce =
n'est pas le cas ... Sous Access on peut d=E9signer un enregistrement par=
=20
sa position dans un formulaire, par CurrentRecord -ce qui n'est pas=20
valable dans une requ=EAte, en dehors du formulaire, =E0 moins de cr=E9er=
un=20
champ =E0 cette intention et de le renseigner avec une requ=EAte astuce. =
Est-ce que dans un DataSet il existe quelque chose pour d=E9signer le=20
num=E9ro de ligne de l'enregistrement courant ?
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
Patrice
Bonjour,
DataGridView c'est en Windows Forms. Cela serait un site web (tu en parles à un moment) et une GridView ?
Pour faire au plus simple et au plus sûr, ma préférence personnelle serait plutôt de faire une page séparée qui permet simplement d'entrer les anciennes valeurs et les valeurs à remplacer avec les vérifications voulues et le tour est joué (avec une vérification au préalable que l'on a bin qu'une seule ligne avec ce n° de poste) plutôt que de modifier qq chose qui marche et qui sera à remettre dans l'état précédent...
En plus la saisie en retard semble possible et cela risque fort de se reproduire donc cela sera sans doute utile de garder cette possibilité sous le coude...
Dans l'absolu l'utilisation d'un n° auto serait sans doute une bonne idée (ce qui n'empêche pas d'avoir un index unique sur les autres champs). Normalement une clé primaire ne devrait jamais être modifiée (et dans ce cas la GridView condigurée normalement sera capable de gérer la modif).
Sinon : Access ne supporte pas les paramètres nommées. Dans un DataSet il n'y a pas vraiment d'enregistrement courant. La GridView doit garder trace par contre de l'enregistrement courant (ou plus exactement de celui sélectionné ou en cours de modification). Je ne vois pas de problème particulier pour la GridView. Je pense que pour l'instant le gros problème doit plutôt être au niveau de la requête (visiblement soir la maj n'est pas effectué, soit la requête est incorrecte et la mise à jour ne se fait pas)...
-- Patrice
"Gloops" a écrit dans le message de news: % Bonjour tout le monde,
Avec un DataGridView, je veux mettre à jour une table Access.
Tant que je m'attaque à un champ non clef, je peux dire que ça se passe plutôt bien, enfin après avoir saisi la requête moi-même.
La clef est composée de quatre champs, entier, chaîne de caractères, date, entier.
Il s'est trouvé qu'un enregistrement a été créé avec une erreur au niveau de la date dans la clef. L'enregistrement a été créé avec la date système au moment de sa création, et pas de pot il a été saisi avec retard. Cette création a été faite en runtime Access, or comme je ne dispose plus d'Access je ne peux corriger le code responsable de l'erreur, de toute manière ça aurait été hors sujet ici.
Le premier champ, entier, s'appelle numéro de poste. Il se trouve qu'un seul enregistrement porte le numéro de poste sur lequel je veux corriger la date dans la clef, donc SQL peut très bien s'en sortir.
Je me suis dit que ça pouvait être intéressant de tenter cet exercice avec le DataGridView, en n'oubliant pas de remettre celui-ci dans son état normal après.
J'ai bricolé la requête Update pour que seul le numéro de poste soit considéré comme clef, et que les autres champs soient modifiés par la requête.
Premier essai, plantage (affichage de la page d'erreur du site web). J'avais enlevé l'attribut ReadOnly juste à la colonne qui m'intéressait, et on m'a objecté une erreur de type. Donc, j'imagine que les champs se sont décalés d'autant de crans qu'il y avait de colonnes en ReadOnly à mauvais escient.
J'ai enlevé l'attribut ReadOnly à toutes les colonnes sauf le numéro de poste. Cette fois, la modification de la date n'a pas provoqué de plantage. Seul inconvénient, après la validation l'enregistrement se réaffiche avec la date qu'il avait avant la mise à jour.
Il faut dire qu'Access a un moyen très efficace pour repérer les différents paramètres, puisque dans la requête SQL ils sont représentés par chacun un point d'interrogation.
ça va même plus loin, l'assistant Configure DataSource, dans sa fonction Execute Query, propose une boîte de dialogue avec autant de zones de saisie que de paramètres, et un point d'interrogation devant chaque, comme invite de saisie. Donc, sur la première ligne, en face du point d'interrogation on saisit le champ correspondant au point d'interrogation, sur la deuxième ligne, en face du point d'interrogation, on saisit le champ correspondant au point d'interrogation, et ainsi de suite.
Est-ce envisageable de mettre un peu d'ordre dans ce bazar ? Donner des noms aux paramètres pourrait aider, déjà.
J'imaginerais bien aussi de désigner l'enregistrement par son numéro d'ordre, bon ça c'est facile avec une clef NuméroAuto, mais comme ce n'est pas le cas ... Sous Access on peut désigner un enregistrement par sa position dans un formulaire, par CurrentRecord -ce qui n'est pas valable dans une requête, en dehors du formulaire, à moins de créer un champ à cette intention et de le renseigner avec une requête astuce. Est-ce que dans un DataSet il existe quelque chose pour désigner le numéro de ligne de l'enregistrement courant ?
Bonjour,
DataGridView c'est en Windows Forms. Cela serait un site web (tu en parles à
un moment) et une GridView ?
Pour faire au plus simple et au plus sûr, ma préférence personnelle serait
plutôt de faire une page séparée qui permet simplement d'entrer les
anciennes valeurs et les valeurs à remplacer avec les vérifications voulues
et le tour est joué (avec une vérification au préalable que l'on a bin
qu'une seule ligne avec ce n° de poste) plutôt que de modifier qq chose qui
marche et qui sera à remettre dans l'état précédent...
En plus la saisie en retard semble possible et cela risque fort de se
reproduire donc cela sera sans doute utile de garder cette possibilité sous
le coude...
Dans l'absolu l'utilisation d'un n° auto serait sans doute une bonne idée
(ce qui n'empêche pas d'avoir un index unique sur les autres champs).
Normalement une clé primaire ne devrait jamais être modifiée (et dans ce cas
la GridView condigurée normalement sera capable de gérer la modif).
Sinon : Access ne supporte pas les paramètres nommées. Dans un DataSet il
n'y a pas vraiment d'enregistrement courant. La GridView doit garder trace
par contre de l'enregistrement courant (ou plus exactement de celui
sélectionné ou en cours de modification). Je ne vois pas de problème
particulier pour la GridView. Je pense que pour l'instant le gros problème
doit plutôt être au niveau de la requête (visiblement soir la maj n'est pas
effectué, soit la requête est incorrecte et la mise à jour ne se fait
pas)...
--
Patrice
"Gloops" <gloops@invalid.zailes.org> a écrit dans le message de news:
%234o6kD8FKHA.2832@TK2MSFTNGP03.phx.gbl...
Bonjour tout le monde,
Avec un DataGridView, je veux mettre à jour une table Access.
Tant que je m'attaque à un champ non clef, je peux dire que ça se passe
plutôt bien, enfin après avoir saisi la requête moi-même.
La clef est composée de quatre champs, entier, chaîne de caractères,
date, entier.
Il s'est trouvé qu'un enregistrement a été créé avec une erreur au
niveau de la date dans la clef. L'enregistrement a été créé avec la date
système au moment de sa création, et pas de pot il a été saisi avec
retard. Cette création a été faite en runtime Access, or comme je ne
dispose plus d'Access je ne peux corriger le code responsable de
l'erreur, de toute manière ça aurait été hors sujet ici.
Le premier champ, entier, s'appelle numéro de poste. Il se trouve qu'un
seul enregistrement porte le numéro de poste sur lequel je veux corriger
la date dans la clef, donc SQL peut très bien s'en sortir.
Je me suis dit que ça pouvait être intéressant de tenter cet exercice
avec le DataGridView, en n'oubliant pas de remettre celui-ci dans son
état normal après.
J'ai bricolé la requête Update pour que seul le numéro de poste soit
considéré comme clef, et que les autres champs soient modifiés par la
requête.
Premier essai, plantage (affichage de la page d'erreur du site web).
J'avais enlevé l'attribut ReadOnly juste à la colonne qui m'intéressait,
et on m'a objecté une erreur de type. Donc, j'imagine que les champs se
sont décalés d'autant de crans qu'il y avait de colonnes en ReadOnly à
mauvais escient.
J'ai enlevé l'attribut ReadOnly à toutes les colonnes sauf le numéro de
poste. Cette fois, la modification de la date n'a pas provoqué de
plantage. Seul inconvénient, après la validation l'enregistrement se
réaffiche avec la date qu'il avait avant la mise à jour.
Il faut dire qu'Access a un moyen très efficace pour repérer les
différents paramètres, puisque dans la requête SQL ils sont représentés
par chacun un point d'interrogation.
ça va même plus loin, l'assistant Configure DataSource, dans sa fonction
Execute Query, propose une boîte de dialogue avec autant de zones de
saisie que de paramètres, et un point d'interrogation devant chaque,
comme invite de saisie. Donc, sur la première ligne, en face du point
d'interrogation on saisit le champ correspondant au point
d'interrogation, sur la deuxième ligne, en face du point
d'interrogation, on saisit le champ correspondant au point
d'interrogation, et ainsi de suite.
Est-ce envisageable de mettre un peu d'ordre dans ce bazar ?
Donner des noms aux paramètres pourrait aider, déjà.
J'imaginerais bien aussi de désigner l'enregistrement par son numéro
d'ordre, bon ça c'est facile avec une clef NuméroAuto, mais comme ce
n'est pas le cas ... Sous Access on peut désigner un enregistrement par
sa position dans un formulaire, par CurrentRecord -ce qui n'est pas
valable dans une requête, en dehors du formulaire, à moins de créer un
champ à cette intention et de le renseigner avec une requête astuce.
Est-ce que dans un DataSet il existe quelque chose pour désigner le
numéro de ligne de l'enregistrement courant ?
DataGridView c'est en Windows Forms. Cela serait un site web (tu en parles à un moment) et une GridView ?
Pour faire au plus simple et au plus sûr, ma préférence personnelle serait plutôt de faire une page séparée qui permet simplement d'entrer les anciennes valeurs et les valeurs à remplacer avec les vérifications voulues et le tour est joué (avec une vérification au préalable que l'on a bin qu'une seule ligne avec ce n° de poste) plutôt que de modifier qq chose qui marche et qui sera à remettre dans l'état précédent...
En plus la saisie en retard semble possible et cela risque fort de se reproduire donc cela sera sans doute utile de garder cette possibilité sous le coude...
Dans l'absolu l'utilisation d'un n° auto serait sans doute une bonne idée (ce qui n'empêche pas d'avoir un index unique sur les autres champs). Normalement une clé primaire ne devrait jamais être modifiée (et dans ce cas la GridView condigurée normalement sera capable de gérer la modif).
Sinon : Access ne supporte pas les paramètres nommées. Dans un DataSet il n'y a pas vraiment d'enregistrement courant. La GridView doit garder trace par contre de l'enregistrement courant (ou plus exactement de celui sélectionné ou en cours de modification). Je ne vois pas de problème particulier pour la GridView. Je pense que pour l'instant le gros problème doit plutôt être au niveau de la requête (visiblement soir la maj n'est pas effectué, soit la requête est incorrecte et la mise à jour ne se fait pas)...
-- Patrice
"Gloops" a écrit dans le message de news: % Bonjour tout le monde,
Avec un DataGridView, je veux mettre à jour une table Access.
Tant que je m'attaque à un champ non clef, je peux dire que ça se passe plutôt bien, enfin après avoir saisi la requête moi-même.
La clef est composée de quatre champs, entier, chaîne de caractères, date, entier.
Il s'est trouvé qu'un enregistrement a été créé avec une erreur au niveau de la date dans la clef. L'enregistrement a été créé avec la date système au moment de sa création, et pas de pot il a été saisi avec retard. Cette création a été faite en runtime Access, or comme je ne dispose plus d'Access je ne peux corriger le code responsable de l'erreur, de toute manière ça aurait été hors sujet ici.
Le premier champ, entier, s'appelle numéro de poste. Il se trouve qu'un seul enregistrement porte le numéro de poste sur lequel je veux corriger la date dans la clef, donc SQL peut très bien s'en sortir.
Je me suis dit que ça pouvait être intéressant de tenter cet exercice avec le DataGridView, en n'oubliant pas de remettre celui-ci dans son état normal après.
J'ai bricolé la requête Update pour que seul le numéro de poste soit considéré comme clef, et que les autres champs soient modifiés par la requête.
Premier essai, plantage (affichage de la page d'erreur du site web). J'avais enlevé l'attribut ReadOnly juste à la colonne qui m'intéressait, et on m'a objecté une erreur de type. Donc, j'imagine que les champs se sont décalés d'autant de crans qu'il y avait de colonnes en ReadOnly à mauvais escient.
J'ai enlevé l'attribut ReadOnly à toutes les colonnes sauf le numéro de poste. Cette fois, la modification de la date n'a pas provoqué de plantage. Seul inconvénient, après la validation l'enregistrement se réaffiche avec la date qu'il avait avant la mise à jour.
Il faut dire qu'Access a un moyen très efficace pour repérer les différents paramètres, puisque dans la requête SQL ils sont représentés par chacun un point d'interrogation.
ça va même plus loin, l'assistant Configure DataSource, dans sa fonction Execute Query, propose une boîte de dialogue avec autant de zones de saisie que de paramètres, et un point d'interrogation devant chaque, comme invite de saisie. Donc, sur la première ligne, en face du point d'interrogation on saisit le champ correspondant au point d'interrogation, sur la deuxième ligne, en face du point d'interrogation, on saisit le champ correspondant au point d'interrogation, et ainsi de suite.
Est-ce envisageable de mettre un peu d'ordre dans ce bazar ? Donner des noms aux paramètres pourrait aider, déjà.
J'imaginerais bien aussi de désigner l'enregistrement par son numéro d'ordre, bon ça c'est facile avec une clef NuméroAuto, mais comme ce n'est pas le cas ... Sous Access on peut désigner un enregistrement par sa position dans un formulaire, par CurrentRecord -ce qui n'est pas valable dans une requête, en dehors du formulaire, à moins de créer un champ à cette intention et de le renseigner avec une requête astuce. Est-ce que dans un DataSet il existe quelque chose pour désigner le numéro de ligne de l'enregistrement courant ?
Gloops
Patrice a écrit, le 16/08/2009 20:35 :
Bonjour,
Bonjour,
DataGridView c'est en Windows Forms. Cela serait un site web (tu en par les à un moment) et une GridView ?
Effectivement, j'ai développé ça en Winform. Par ailleurs j'ai comm encé à faire la même chose en web, enfin ça je crois qu'il faudra y reve nir.
Pour faire au plus simple et au plus sûr, ma préférence personnel le serait plutôt de faire une page séparée qui permet simplement d'entrer l es anciennes valeurs et les valeurs à remplacer avec les vérifications voulues et le tour est joué (avec une vérification au préalable que l'on a bin qu'une seule ligne avec ce n° de poste) plutôt que de modifier qq c hose qui marche et qui sera à remettre dans l'état précédent...
Effectivement c'est bien ce que j'ai fait, des contrôles de saisie sur le côté apparaissent en cliquant sur un bouton de mise à jour, et lorsqu'on reclique sur ce bouton les contrôles disparaissent après mi se à jour. On dispose donc de l'ancienne valeur, dans la DataGridView, et de la nouvelle, dans le contrôle de saisie (TextBox ou DateTimePicker).
Comme je le dis dans un autre fil ça y est c'est rôdé. Il se peut q ue j'aie un peu manqué de rigueur pour mettre les réponses au bout des questions.
Un souci apparaît pour la mise en forme des autres champs. J'ai mis ç a au point pour un champ à la fois dans la procédure événementielle DataEndEdit de la DataGridView (fil démarré le 11 à 14:53).
En plus la saisie en retard semble possible et cela risque fort de se reproduire donc cela sera sans doute utile de garder cette possibilité sous le coude...
En fait, c'était, à l'utilisation de la base Access, un oubli de modifier la date lors de la création de l'enregistrement, qui a donc é té créé avec la date système qui est la date par défaut.
Le fait d'avoir arrêté quelques mois d'utiliser la base fait apparaî tre les choses sous un autre angle, et met effectivement en évidence l'intérêt de pouvoir corriger après coup une erreur de saisie. Du c oup ça fait un exercice de style ...
Dans l'absolu l'utilisation d'un n° auto serait sans doute une bonne idée (ce qui n'empêche pas d'avoir un index unique sur les autres champs). Normalement une clé primaire ne devrait jamais être modifiée (et dans ce cas la GridView condigurée normalement sera capable de gérer la modif).
Sinon : Access ne supporte pas les paramètres nommées. Dans un Data Set il n'y a pas vraiment d'enregistrement courant. La GridView doit garder tr ace par contre de l'enregistrement courant (ou plus exactement de celui sélectionné ou en cours de modification). Je ne vois pas de problè me particulier pour la GridView. Je pense que pour l'instant le gros probl ème doit plutôt être au niveau de la requête (visiblement soir la maj n'est pas effectué, soit la requête est incorrecte et la mise à jour ne se fait pas)...
Effectivement, avec le CellEndEdit j'ai pu voir de plus près ce qui se passe et corriger les problèmes de syntaxe plus facilement. Il semble que ce soit surtout les valeurs nulles qui mériteraient un approfondissement.
Merci pour ces éclairages.
Patrice a écrit, le 16/08/2009 20:35 :
Bonjour,
Bonjour,
DataGridView c'est en Windows Forms. Cela serait un site web (tu en par les à
un moment) et une GridView ?
Effectivement, j'ai développé ça en Winform. Par ailleurs j'ai comm encé
à faire la même chose en web, enfin ça je crois qu'il faudra y reve nir.
Pour faire au plus simple et au plus sûr, ma préférence personnel le serait
plutôt de faire une page séparée qui permet simplement d'entrer l es
anciennes valeurs et les valeurs à remplacer avec les vérifications voulues
et le tour est joué (avec une vérification au préalable que l'on a bin
qu'une seule ligne avec ce n° de poste) plutôt que de modifier qq c hose qui
marche et qui sera à remettre dans l'état précédent...
Effectivement c'est bien ce que j'ai fait, des contrôles de saisie sur
le côté apparaissent en cliquant sur un bouton de mise à jour, et
lorsqu'on reclique sur ce bouton les contrôles disparaissent après mi se
à jour. On dispose donc de l'ancienne valeur, dans la DataGridView, et
de la nouvelle, dans le contrôle de saisie (TextBox ou DateTimePicker).
Comme je le dis dans un autre fil ça y est c'est rôdé. Il se peut q ue
j'aie un peu manqué de rigueur pour mettre les réponses au bout des
questions.
Un souci apparaît pour la mise en forme des autres champs. J'ai mis ç a
au point pour un champ à la fois dans la procédure événementielle
DataEndEdit de la DataGridView (fil démarré le 11 à 14:53).
En plus la saisie en retard semble possible et cela risque fort de se
reproduire donc cela sera sans doute utile de garder cette possibilité sous
le coude...
En fait, c'était, à l'utilisation de la base Access, un oubli de
modifier la date lors de la création de l'enregistrement, qui a donc é té
créé avec la date système qui est la date par défaut.
Le fait d'avoir arrêté quelques mois d'utiliser la base fait apparaî tre
les choses sous un autre angle, et met effectivement en évidence
l'intérêt de pouvoir corriger après coup une erreur de saisie. Du c oup
ça fait un exercice de style ...
Dans l'absolu l'utilisation d'un n° auto serait sans doute une bonne idée
(ce qui n'empêche pas d'avoir un index unique sur les autres champs).
Normalement une clé primaire ne devrait jamais être modifiée (et dans ce cas
la GridView condigurée normalement sera capable de gérer la modif).
Sinon : Access ne supporte pas les paramètres nommées. Dans un Data Set il
n'y a pas vraiment d'enregistrement courant. La GridView doit garder tr ace
par contre de l'enregistrement courant (ou plus exactement de celui
sélectionné ou en cours de modification). Je ne vois pas de problè me
particulier pour la GridView. Je pense que pour l'instant le gros probl ème
doit plutôt être au niveau de la requête (visiblement soir la maj n'est pas
effectué, soit la requête est incorrecte et la mise à jour ne se fait
pas)...
Effectivement, avec le CellEndEdit j'ai pu voir de plus près ce qui se
passe et corriger les problèmes de syntaxe plus facilement. Il semble
que ce soit surtout les valeurs nulles qui mériteraient un
approfondissement.
DataGridView c'est en Windows Forms. Cela serait un site web (tu en par les à un moment) et une GridView ?
Effectivement, j'ai développé ça en Winform. Par ailleurs j'ai comm encé à faire la même chose en web, enfin ça je crois qu'il faudra y reve nir.
Pour faire au plus simple et au plus sûr, ma préférence personnel le serait plutôt de faire une page séparée qui permet simplement d'entrer l es anciennes valeurs et les valeurs à remplacer avec les vérifications voulues et le tour est joué (avec une vérification au préalable que l'on a bin qu'une seule ligne avec ce n° de poste) plutôt que de modifier qq c hose qui marche et qui sera à remettre dans l'état précédent...
Effectivement c'est bien ce que j'ai fait, des contrôles de saisie sur le côté apparaissent en cliquant sur un bouton de mise à jour, et lorsqu'on reclique sur ce bouton les contrôles disparaissent après mi se à jour. On dispose donc de l'ancienne valeur, dans la DataGridView, et de la nouvelle, dans le contrôle de saisie (TextBox ou DateTimePicker).
Comme je le dis dans un autre fil ça y est c'est rôdé. Il se peut q ue j'aie un peu manqué de rigueur pour mettre les réponses au bout des questions.
Un souci apparaît pour la mise en forme des autres champs. J'ai mis ç a au point pour un champ à la fois dans la procédure événementielle DataEndEdit de la DataGridView (fil démarré le 11 à 14:53).
En plus la saisie en retard semble possible et cela risque fort de se reproduire donc cela sera sans doute utile de garder cette possibilité sous le coude...
En fait, c'était, à l'utilisation de la base Access, un oubli de modifier la date lors de la création de l'enregistrement, qui a donc é té créé avec la date système qui est la date par défaut.
Le fait d'avoir arrêté quelques mois d'utiliser la base fait apparaî tre les choses sous un autre angle, et met effectivement en évidence l'intérêt de pouvoir corriger après coup une erreur de saisie. Du c oup ça fait un exercice de style ...
Dans l'absolu l'utilisation d'un n° auto serait sans doute une bonne idée (ce qui n'empêche pas d'avoir un index unique sur les autres champs). Normalement une clé primaire ne devrait jamais être modifiée (et dans ce cas la GridView condigurée normalement sera capable de gérer la modif).
Sinon : Access ne supporte pas les paramètres nommées. Dans un Data Set il n'y a pas vraiment d'enregistrement courant. La GridView doit garder tr ace par contre de l'enregistrement courant (ou plus exactement de celui sélectionné ou en cours de modification). Je ne vois pas de problè me particulier pour la GridView. Je pense que pour l'instant le gros probl ème doit plutôt être au niveau de la requête (visiblement soir la maj n'est pas effectué, soit la requête est incorrecte et la mise à jour ne se fait pas)...
Effectivement, avec le CellEndEdit j'ai pu voir de plus près ce qui se passe et corriger les problèmes de syntaxe plus facilement. Il semble que ce soit surtout les valeurs nulles qui mériteraient un approfondissement.
