Discussion :

[netangel]

Slt à tous,

Quelqu'un saurait-il comment on récupère un champ "auto-increment" lors d'une requete d'insertion dans une table via ADO.NET?

Merci d'avance.

[bidou]

avec une requête qui va dépendre du SGBD

[netangel]

Elle est où la portabilité sous ADO.NET s'il faut modifier le code pour une fonctionnalité au moins aussi basique que fréquemment utilisée?

Est ce que je pourrais avoir un exemple sous un SGBDR de ton choix (de préférence Access,SQl Server ou MySQL qui sont installés sur ma machine)?


Merci pour ta réponse

[The_badger_man]

Si tu veux de la portabilité, tu ne fais pas ta requete dans le code. Tu fais une procédure stockée qui te renvoie l'identifiant.

Sinon la récupération dépend de ton SGBD.

Sous SQL Server il fait utiliser la fonction SCOPE_IDENTITY( ) : ( SELECT SCOPE_IDENTITY() ).

Sous Oracle les champs auto incrémenté n'existent pas (je dis pas de connerie là ? ) c'est remplacé par des séquences.

[bidou]

Franchement elle est bonne celle là. Comme si c'était la faute d'ADO.NET si le jeu préféré des éditeurs de SGBD est d'implémenter chacun des langages à la con plutôt que de suivre les normes SQL...

[netangel]

Sous Oracle les champs auto incrémenté n'existent pas (je dis pas de connerie là ? ) c'est remplacé par des séquences.

On peut simuler les auto increments sous Oracle avec une séquence associé à un TRIGGER.

Franchement elle est bonne celle là. Comme si c'était la faute d'ADO.NET si le jeu préféré des éditeurs de SGBD est d'implémenter chacun des langages à la con plutôt que de suivre les normes SQL...

Je pense pouvoir avancé avec peu de risque de me tromper que pratiquement tous les SGBDR (corrige moi si je me trompe) dispose de cette fonctionnalité sous des noms ou sous des formes différentes. ce qui fait qu'en Java, sous JDBC, il existe une fonctionnalité standard permettant de récupérer ce type de champ (il s'agit de la méthode getGeneratedKeys() de l'interface Statement)! Libre au Driver utilisé de récupérer la bonne valeur.

Et on ne peu pas dire que .NET, comparé à JAVA, soit un modèle de portabilité!