Gestion des champs en auto-incrémentation avec PEAR - PHP - Programmation
Marsh Posté le 13-01-2004 à 21:39:24
il y a peu de chance que cela arrive si tu fais tes query l'une derrière l'autre.
Code :
|
Dans le pire des cas, lock la table (en espérant que ton sgbd le supporte), mais c'est très lourd.
Si ton script s'interrompt juste après le lock, ta table sera figée...
--edit 15/01/2004--
non non ne me remercie pas, c'est normal je suis là pour ça...
Marsh Posté le 16-01-2004 à 08:59:56
ethernal a écrit : il y a peu de chance que cela arrive si tu fais tes query l'une derrière l'autre.
|
Comme tu as pu le lire dans mon premier post, la méthode que tu me proposes est celle que j'ai mis en place (mais sans le lock). En tout cas, c'est sympa de m'avoir répondu, car je vois que ce que j'ai fait n'est pas trop débile...
Marsh Posté le 16-01-2004 à 19:15:52
oui, c'est exact, c'est la même méthode avec la précision de faire les query l'une derrière l'autre.
(Je l'ai précisé pcq la première fois que j'ai dû faire cela en Cobol, je créais mon ID lors de la demande de création d'un nouvel élément et je lockais la table... et évidemment cela change tout , le temps que la personne valide son enregistrement, les autres étaient bloquées.)
La seule possibilité, est de faire tes querys en "1 bloc".
Je pense qu'il y a déjà eu qq messages concernant les "Lock", mais cette méthode a toujours été déconseillée (si le dé-lock ne se fait pas, la table est inutilisable).
Marsh Posté le 19-01-2004 à 14:28:09
ethernal a écrit : oui, c'est exact, c'est la même méthode avec la précision de faire les query l'une derrière l'autre. |
c'est clair...(pour le de-lock)
Marsh Posté le 12-01-2004 à 15:34:43
Voilà, je suis en train de développer un site en PHP qui repose sur une BD (ici, MySQL, mais ça pourrait être une autre, genre Oracle). Pour être (en théorie) indépendant de la BD utilisée, j'utilise les primitives de la bibliothèque PEAR.
Seulement, d'après mon bouquin de PHP (la bible PHP), les champs auto-incrémentés n'exsitent pas sur toutes les SGBD. Il conseille donc d'utiliser les séquences (les fct createSequence, dropSequence et nextId). Sauf que dans l'exemple de mon bouquin, la table est remplie d'un coup, donc la fonction nextId retourne les valeurs de 1 à n. Dans mon cas, je veux que ça retourne le bon ID, genre, si j'ai déjà 3 enregistrements dans ma table, je veux que nextId retourne 4.
Mais voilà, je n'y suis pas parvenu. J'ai essayé de faire un while sur nextId pour que, une fois arrivé à la fin de la séquence, la fonction renvoie une erreur, mais je boucle à l'infini (et en plus, ce genre de méthode serait très longue dans le cas d'un grand nb d'enregistrements).
J'ai donc trouvé comme solution de secours, retourner l'ID max et l'incrémenter. Mais j'ai peur qu'entre la première requête (récup de l'ID max) et la requête INSERT, il y ait eu une autre insertion et que par conséquent, mon ID récupéré ne serait plus bon ...
Vous pouvez m'aider, svp? Merci beaucoup...