Discussion :

[swirtel]

Je me souviens il y a fort longtemps (quelques mois), lors d'une formation sur le PL/SQL, j'avais vu l'instruction "EXECUTE IMMEDIATE" qui permettait de créer du SQL Dynamique.
J'ai trouvé cette instruction géniale; car en la couplant avec "RETURNING INTO", elle me retournait l'ID du dernier record qui avait été inséré dans la base de données.

J'aurais aimé savoir si les normes SQL ont envisagées cette instruction et si par exemple, certains SGBDR tel que SQL Server 2000 ont cette fonctionnalité fort intéressante.

Sinon, pourriez-vous me dire comment faites-vous pour récupérer l'ID du tout dernier record, en étant certain de ne pas vous tromper ?

Au cas où, pour ceux que cela intéresse, voici à quoi ressemble l'instruction "EXECUTE IMMEDIATE" http://sheikyerbouti.developpez.com/execute_immediate/.

[SQLpro]

La norme SQL:2003 à consacré l'existence de deux méthodes différentes d'auto incrémentation, soit avec une séquence (Oracle, DB2, Interbase...) soit avec l'attribut IDENTITY (SQL Server, DB2, Sybase...).

Cependant la norme passe totalement sous silence la récupération de la dernière valeur de l'ID.
Mais c'est faisable en relisant la valeur du séquenceur sans l'incrémenter et sous MS SQL Server, la variable @@identity fournit le dernier identifiant inséré dans la session quelque soit la table.

A +

[swirtel]

Mais est-ce que ce procédé ne risque pas de poser de problèmes en cas d'utilisation de connections simultanées ?

Jusqu'à présent, je fais un INSERT et ensuite je fais un SELECT afin de récupérer l'ID, mais ce qui m'ennuie, c'est si quelqu'un m'ajoute un doublon et que cela soit permis dans la logique du soft, alors je vais être ennuyé.

Je pensais à autre chose, créer un champ supplémentaire pour chaque table que je gère. Lors de l'insertion d'un nouveau record, je génère de manière aléatoire une clé qui me permettra de retrouver LE record que je viens d'insérer, tout en étant sûr de ne pas me tromper, même en cas de doublon.

Une autre idée ???

[SQLpro]

Jusqu'à présent, je fais un INSERT et ensuite je fais un SELECT afin de récupérer l'ID, mais ce qui m'ennuie, c'est si quelqu'un m'ajoute un doublon et que cela soit permis dans la logique du soft, alors je vais être ennuyé.

Ha ben si tu fait ça t'es dans la merde ! C'est la pire des choses... parce que rien ne peut interdire un utilisateur de rentrer une ligne entre ta premiere reqête INSERT et la seconde SELECT.

C'est pour cela que les éditeurs de SGBDR ont ineventé ces mécanismes !

Je pensais à autre chose, créer un champ supplémentaire pour chaque table que je gère. Lors de l'insertion d'un nouveau record, je génère de manière aléatoire une clé qui me permettra de retrouver LE record que je viens d'insérer, tout en étant sûr de ne pas me tromper, même en cas de doublon.

Et pourquoi réinventer le roue et faire pire que ce que l'éditeur te donne, voire même horriblement contre performant ???

A lire sur le sujet : http://sqlpro.developpez.com/cours/clefs/

A +

[swirtel]

Ha ben si tu fait ça t'es dans la merde ! C'est la pire des choses... parce que rien ne peut interdire un utilisateur de rentrer une ligne entre ta premiere reqête INSERT et la seconde SELECT.

L'utilisateur n'a pas le droit à aller modifier la requête, vu qu'elle se trouve à l'intérieur d'un code source d'une application.

Je pensais à autre chose, créer un champ supplémentaire pour chaque table que je gère. Lors de l'insertion d'un nouveau record, je génère de manière aléatoire une clé qui me permettra de retrouver LE record que je viens d'insérer, tout en étant sûr de ne pas me tromper, même en cas de doublon.

Et pourquoi réinventer le roue et faire pire que ce que l'éditeur te donne, voire même horriblement contre performant ???

A lire sur le sujet : http://sqlpro.developpez.com/cours/clefs/

Merci concernant cette doc, l'exemple de la dernière clé insérée dans une table, est très intéressante, car tant que l'on se trouve dans la transaction en cours, on est certain de ne pas avoir d'accès concurrent qui pourrait perturber le résultat retourné par le SGBD.

Mais le fait de penser de cette manière, n'y a-t-il pas un risque de performances ? Aussi bien au niveau SGBD qu'au niveau des ressources réseaux ? Par exemple, pour ajouter un record, vérifier qu'il n'existe pas de doublons, insérer le nouveau record, faire un select pour récupérer l'id de ce record.

3 opérations simplement pour ajouter un élément dans la table.
Tu pourrais me dire, "pourquoi ne fais-tu pas une fonction au niveau du SQL qui ajoute et te retourne directement l'ID ?".
J'ai déjà proposé l'idée à mes collègues, et on m'a dit tout simplement que l'on risquait d'avoir certains problèmes avec des SGBD qui ne supportent pas les fonctions ou procedures, et au niveau de la portabilité du code SQL.

bien à toi,

Je vais continuer à lire ton cours sur les clefs.

Stéphane