http://www.kamath.com/tutorials/tut007_identity.asp

Article intéressant mais qui ne répond pas à ma question ;p
@@IDENTITY est spécifique pour une connection donné et ça ne m'arrange pas.

Voici le cas concret, une table T est remplis sous Access avec 9 valeurs (de 1 à 9) en guise de clé primaire et à chaque enregistrement on associe un simple nom.
Si on supprime l'enregistrement 6 et que l'on en recré un sous Access même si on rebooté le PC, l'ID suivant sera 10.

Toutes mes commandes se font à base OleDbCommand, ExecuteReader ou ExecuteScalar.

Donc est ce qu'il faut lors du INSERT INTO préciser le nouvel ID ou bien faut-il ignorer ce champ et laisser la base l'auto incrémenter tout seul ?

----------------------------
C++ forever
C# amateur

Moi je dirais que l'autoincrémentiel est ce qu'il y a de plus sure. Car prenons un exemple irréaliste qu'un client veuille insérer dans un trou en meme temps qu'un autre, ils se retrouve avec le meme id. Laissez faire le système est à coup sur une bonne sécurité, c'est sur qu'avoir des trucs ça le fait pas mais bon
De toute façon tu n'arrivera jamais à faire du forcing sur un autoincrémentiel qu'il soit en access ou sql.

Amicalement TMCUH

n'empeche que ca répond pas à la question....

----------------------------
C++ forever
C# amateur

et donc si on lui précise pas, est ce que le INSERT INTO plante parce qu'on ne lui a pas spécifié de champ ?

----------------------------
C++ forever
C# amateur

Réponse : non il crée cela tout seul
Ok je suis un sombre crétin, je retourne dans ma caverne

----------------------------
C++ forever
C# amateur

lol Soit pas trop dur avec toi même ! ^^