DataGridview et Access : modif de champ clef

Le
Gloops
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 pas=
se
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 av=
ec
retard. Cette création a été faite en runtime Access, or comme je n=
e
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 corrige=
r
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 exerci=
ce
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 soi=
t
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éres=
sait,
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ér=
o 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 fonct=
ion
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 ?
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Patrice
Le #19938791
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" %
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
Le #19945141
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.
Publicité
Poster une réponse
Anonyme