Bonjour,
 
Je souhaite savoir s'il arrive qu' "auto increment" affecte à un champ indexé et unique une valeur déjà affectée à un autre enregistrement ?
Autrement dit, la valeur retourné par "auto increment" peut-elle être considérée comme fiable à 100% ?
 
Merci !!!!
 
P.S. : ça parait ridicule comme question, mais c'est parce que je développe avec un autre SGBD à qui il arrive de fournir un numéro déjà utilisé ... !!!

non, mysql bouche les trous, mais ne peut pas donner un numéro déjà en cours d'utilisation.
 
par contre, un max(id) ne retourne pas forcément le dernier numéro, puisqu'il bouche les trous.
 
florentg > bah ouais, ça peut arriver. sous oracle par exemple, il n'y a pas d'auto-incrément. on utilise des sequences à la place, qui ne sont liables à une table que grace à un trigger.
suffit de pas savoir écrire un trigger correctement, et on est foutu de générer des doublons avec une séquence (faut le faire, mais y'a pas de limites à la stupidité humaine, genre mettre des " dans du SQL, ou des ` autour des noms de champs... tu vois de quoi je veux parler ? )

'tain C'est pour tenter de faires des clé primaires à partir de 52 champs ?

hein ? de quoi donc ?
 
sinon, autre cas classique, c'est la ch'tite requête qui permet de connaître le dernier numéro de ligne inserré. souvent, le SGBD a bien créé deux lignes, mais on a récupéré deux fois le même numéro de ligne depuis deux process différent au lieu que chacun récupère le numéro de la ligne qu'il a créé (ça m'est arrivé avec un code de goret avec SQL Server : récupéré le dernier numéro de ligne créé dans le scope global au lieu de le chercher dans la connection) du coup après on a l'impression que le sgbd s'est croûté, mais en fait c'est surtout le code autour qui est bon à mettre à la poubelle

Nan j'veux dire, de manière générale, on fout toujours un pauvre int(32) pour être sûr que c'est unique, ça me paraît normal d'avoir ça en option de champs... Sauf pour les intégristes qui ne jurent que par des trucs naturels

le problème de mv1, c'est que nombre de SGBD (MySQL, SQL Server, Access, PostGre, etc.) permettent de spécifier un compteur automatique pour un champ.
 
Là, ton champ c'est la clé primaire (donc avec une contrainte d'unicité dessus).
 
Mais parfois, quand le SGBD est encore plus pourri que MySQL (comme quoi, tout peut arriver) le compteur automatique se mélange les pinceaux et va retourner deux fois le même nombre. Ainsi, alors que le champ aurait dû être unique, il ne l'est plus, et ton insert te pète à la gueule sans raison.
 
Et là mv1 veut être sûr que MySQL lui fera pas ce coup-là. Genre, t'imagine, il est 17h50, t'es crevé, t'as qu'une envie, c'est de quitter le boulot. T'attends, les yeux rivés sur l'h'orloge de Windows. 17h59m58s, 17h59m59s... (vivivi !!!!) et 17h00m00s
Et là tu te tire une balle.
 
Ben ouais, y'a des SGBD qui sont capables de ce genre de miracles, et sans observer de changement d'heure d'hivers

Vous voulez un nom ?

T'as tout compris !!!

si tu veux pour le nom, balance

4e Dimension, avec sa jolie commande "Numerotation automatique".
On est obligé d'effectuer une vérification avant de stocker son enregistrement, sinon, au bout d'un moment : PAF !!!!
 
Gare au Gorille !!!

faut dire qu'avec un nom pareil fallait s'en douter

c'est pas standard, c'est illisible, et en plus des fois ça marche pas (genre chais plus qui qui faisait un :

Et qui recevait un message d'erreur.

 
tes " sont peut-être dans le SQL là ?
 
moi je parle du SQL, pas de tes variables PHP.
y'a une légère différence.

ben non...
 
Arf, ben si (là c'est la totale de chez totale )
 
Il faut écrire :

 
A la base, c'est quand même légèrement plus lisible non ?
Et surtout tu renvoies du SQL 100% correct.
Si demain tu dois changer ton SGBD pour un autre, alors ça marchera.
 
A noter aussi les petits malins qui font :
 

 
C'est une hérésie qui mérite le bûcher.
 
Le SQL n'est pas POSIX, donc les échappements POSIX ne s'y appliquement pas. SQL, c'est la norme ANSI qui est derrière, donc on respecte la norme ANSI, c'est à dire que les caractères d'échappement, c'est le caractère spécial qui est doublé :
 

 
Seul Oracle et MySQL supportent les échappements POSIX, et comme par enchangement, c'est les deux SGBD qui sont les moins conforme à la norme SQL...
 
Et l'un comme l'autre supporte l'ANSI, donc il n'y a aucune raison de faire du POSIX.

Si tu ne veux pas antislasher, tu peux toujours utiliser la double quote comme séparateur de chaîne dans le PHP.
 
D'ailleurs, il me semble que cette syntaxe doit marcher :
 

 
(c'est d'ailleurs plus performant que les concaténations)

c ballo madame chombier... fallait écouter RTL

Non suffit de connaitre php et savoir que l'évaluation dans les chaines se limite aux variables de type chaines de caractères
 
Obligé de sortir de la chaine pour faire sortir quoi que ce soit d'un tableau
 
Mais pour le coup c'est plus lisible avec des "

à mon goût que d'échapper tous les 2 mots  

je maintiens que c'est quand même plus lisible comme ça :

(c'est un avis personnel ceci dit)

C'est tout sauf lisible que d'inclure comme ça des variables PHP dans une chaînede texte SQL sans vraiment les "sortir" de la chaîne !
 
Rien de plus lisible qu'un bon vieux  

 
Là au moins, on voit tout de suite ou sont les variables, leurs nom, toussa ! C'est pas "perdu" au milieu de la chaine de caractère ! Qui plus es lorsqu'il y a de la coloration syntaxique !

Sauf que mettre des " dans du sql c'est caca pourri

Le truc, c'est que ta requête SQL, au final, elle ressemble à ça :

 
Mais mettre des " dans du SQL, spa bien ! Faut mettre des ' ! Comme ce que donne mon exemple :

 
 
 
edit :  

Kao98 > c'est une question d'avis (pour les variables noyées au milieux du SQL)
pour moi le fait d'assimiler les variables à des variables SQL ne me dérange pas. peut-être parceque j'ai l'habitude de travailler avec des requêtes SQL paramétrée
 
en tout cas, je hais les concaténations, c'est trop laid (et lent) (et lourd) (et lipideux) (et laborieux) (et larmoyant) (et livide) (et lavasse) (et long) (et l...chuis à court de vocabulaire là )
 
 
(et me sors pas que c'est limpide, ludique, lucide, ... )

Si t'aimes pas les trucs laid / lent / lourd / ..., faut pas faire de php !    
 
[/troll]

ben justement j'en fait pas

moi je fais des :
 

 

 
Plus exactement...
 

Pour en revenir aux variables en SQL : moi aussi j'ai l'habitude de bosser avec des variables (je bosse sous SQL Server ces temps-ci).
Disons que, quand j'écris une requête SQL que je passe ensuite dans une variable dans un autre langage (VB, php, ...) du genre  
 
mavar = "SELECT ..."
 
ce n'est peut-être, comme tu le dis, qu'une question d'habitude, ou un avis personnel, mais je met un point d'honneur à sortir mes variables PHP de ma chaine de texte (et donc de faire comme l'exemple que j'ai mis plus haut). Histoire de bien différencier, comme je le disais, le SQL de l'autre langage de programmation, justement pour faire la part des chose entre SQL et ce qui ne l'est pas.
 
M'enfin, spa la peine de s'attarder là-dessus !
 
(note : suis crevé, fin de journée oblige, donc désolé si c'est pas très clair ce pavé de texte )

Moi, c'est plus du T-SQL en fait !
Mais C# (ou MC++ ) avec Oracle, je connais (un peu) aussi  

Ici, c'est C# avec Oracle en effet

Disons que noyer les variables PHP dans le SQL, ça permet, sans rien toucher mise à part le $ à transformer en : ou @, de passer à une syntaxe propre, à base d'objets Command et Parameters (qui évitent les erreurs de type et de SQL Injection).
C'est pour cette ressemblance que j'aime bien la syntaxe sans concaténation (plus le fait que les concaténations, moins on en fait mieux c'est, mais bon, là c'est de l'optimisation à deux balles, faut pas que ça vienne polluer la lisibilité, je suis d'accord)