Discussion :

[laumon]

Bonjour,
Note : je travaille en code et non pas avec le designer.

J'ai une table SQL Serveur 'MaTable' avec un champ 'MaCle' de type 'compteur'. J'affiche les champs en faisant des bind sur des textbox.
Lorsque je sauvegarde un nouvel enregistrement (ajout d'enregistrement) avec

Code :

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

1
2
3
bsMaTable.EndEdit()
builder.GetUpdateCommand()
daMaTable.Update(dsMaTable.Tables("MaTable"))

j'ai bsMaTable.Current("MaCle").ToString qui reste à System.DbBull.
(Pour info, si je sauvegarde une seconde fois cet enregistrement sans rien modifier, rien ne se passe, si je modifie un élément j'ai un message 'violation de l'accès concurrentiel : updateCommand a affecté 0 enregistrements' => l'enregistrement s'est bien créé mais je ne peux pas le modifier si je ne ferme pas mon form.)

Soit je m'y prends mal, soit je loupe quelque chose.
Quelqu'un peut-il m'aider?
Merci.

[MABROUKI]

bonjour,laumon
est ce que le champ cle tu le visualise dans tes textbox.il faut eviter ca parce qu'un utilisateur peut taper n'importe quoi.
ensuite il est gere normalement par le "schema de la table",c.a.d sa structure qui est importe par le dataset apres connexion a la BD.
S'il le moteur de bd de sql server refuse de valider le champ cle,c'est qu'il n'est pas correct.

bon code...

[laumon]

Merci pour cette proposition mais ce n'est pas là que se trouve le problème.
Il semble que ce soit un souci avec .net si on ne passe pas par le designer pour accéder aux données. Je vais donc via une transaction rechercher la clé incrémentielle de ma table et recharger mon dataset avec. C'est lourd et c'est dommage de devoir faire ainsi... Mais bon ça marche, on se retrouve comme en VB6!
Si jamais quelqu'un a une solution plus 'automatique' je suis preneur.

[sinople]

Il faut savoir que les clefs générée dans le dataset n'ont pas forcément de correspondance avec celle générée par la BD (quelqu'un peut insérer un autre enregistrement entre temps).

C'est un sujet largement discuté sur le net, tu trouveras de la lecture sur le sujet si tu cherches.

Une solution simple:

Ne pas mettre d'incrément automatique et le réaliser à la main en récupérant l'ID max par une requête (sur la BD pas le dataset!) avant. Pas forcément très joli car on court-circuit l'utilisation des tableAdapters.

Solution plus complexe mais plus dans l'esprit ADO.Net:

Effacer dans le dataset le nouvel enregistrement après un update et mettre à jour le dataset avec un merge afin de récupérer le nouvel enregistrement avec l'identifiant généré par la base de donnée.

[laumon]

Merci Sinople. Ta solution 'dans l'esprit .net' est celle que j'adopte lorsque je travaille avec des datagridview, toute la grille se met à jour et je ne me soucie pas de la ligne où il se trouvait (si j'ai un tri sur une autre colonne que la clé).
Par contre j'ai un exemple d'écran ouvert en mode ajout uniquement sur des champs (textbox, combos etc.). Lorsque l'utilisateur sauvegarde, je me dois de récupérer la clé autoincrémentée car je ne ferme pas et l'utilisateur peut faire des modifications sur sa saisie. Donc je me charge de la gestion des écritures en base. Effectivement, l'autre solution est de gérer l'autoincrément de façon manuelle. Bref, c'est comme avant (avant .net = VB6 pour ma part). Je suis un peu déçu par cette constatation mais je gère.
Merci encore et que ce post puisse aider les 'nouveaux'.

[sinople]

Lorsque l'utilisateur sauvegarde, je me dois de récupérer la clé autoincrémentée car je ne ferme pas et l'utilisateur peut faire des modifications sur sa saisie

Peut être qu'il faut alors syncro le dataset et la BD, et donc réaliser l'insertion à un autre moment ?