Il est possible de récupérer l'auto_increment d'une table grâce à la commande : il te suffira ensuite de récupérer le champ qui t'intéresse grâce à un tableau.

Tu peux également modifier cette auto_increment avec: (à manipuler avec précaution)

Tchao

Maintenant, on est d'accord !!!

Un script de transfert de bdd ne doit pas être un script utilisé régulièrement !!!

Après, chacun à sa manière de faire !!!

Pour appuyer pascaltje, je dirais qu'on peu avoir besoin d'un script "jetable" lors d'une migration d'un système vers un autre :
jetable parce que l'entreprise ne fera pas ce genre de manipulation toutes les semaines

idem pour une restauration.

Pour appuyer pascaltje, je dirais qu'on peu avoir besoin d'un script "jetable" lors d'une migration d'un système vers un autre : jetable parce que l'entreprise ne fera pas ce genre de manipulation toutes les semaines, et incontournable parce qu'il n'y a pas vraiment moyen de faire autrement sans tout se coltiner à la main ce qui est inenvisageable dans 99% des cas à cause du nombre d'entrées beaucoup trop important.

@zeus
au risque de me repeter, c'est pour initialiser une base.

Les scripts jetables, ça existe (migration de données par exemple). Et je les fais bien, même si la méthode ne te plait pas.

Dans la majorité des cas, j'essaie de faire du pérenne (codage objet, DAO, classes techniques, architecture, commentaires et documentation) pourtant certains scripts ne servent qu'une fois.

A+

Pascal

c'est sur, on peut toujours tout faire, maisle but du jeu c'est de le faire vite

C'est là où je ne suis pas d'accord avec toi !!!!

Je sais que dans le monde professionnel, on ne fait pas toujours tout bien, mais un remplissage de base de données depuis des fichiers externes ne devrait pas être régulier ou bien c'est qu'il y a eu un problème lors de la conception de l'application.

En partant de là, qu'est-ce qui empêche d'avoir un script qui mets 2minutes à s'executer si tu t'en sers 2 fois et qu'il est abandonné, ou bien que tu t'en sers 1 fois par mois ???

Je ne dit pas que tout le monde doit suivre mon avis, mais JE pense que ce n'est pas viable de fonctionner comme ça, ou du moins juste de facon temporaire

Franchement, entre nous, si le transfert doit être fait régulièrement, c'est un problème de conception !!!!

Ensuite, tu peut créer un nouvel id et récupérer l'ancien dans un champ non auto_increment !!!

Mais je pense que ton exemple est ponctuel et que en aucun cas il ne doit être une excuse pour ne pas appliquer ce que j'ai dit plus haut !!!

Et, pour être en train de transferer et d'adapter des données d'une bdd à une autre en ce moment, je peux te dire que rien n'est impossible et que, même avec de gros traitements, tu peut tout remettre à plat

c'était une initialisation, j'ai tout scripté en procédures stockées + lots DTS (trucs pour manipuler les données dans les transferts sous SQL Server).

c'est sur, on peut toujours tout faire, maisle but du jeu c'est de le faire vite et bien, donc j'ai pris cette solution. je pouvais aussi creer des champs en plus, des tables de correspondance...

A+

Pascal

Franchement, entre nous, si le transfert doit être fait régulièrement, c'est un problème de conception !!!!

Ensuite, tu peut créer un nouvel id et récupérer l'ancien dans un champ non auto_increment !!!

Mais je pense que ton exemple est ponctuel et que en aucun cas il ne doit être une excuse pour ne pas appliquer ce que j'ai dit plus haut !!!

Et, pour être en train de transferer et d'adapter des données d'une bdd à une autre en ce moment, je peux te dire que rien n'est impossible et que, même avec de gros traitements, tu peut tout remettre à plat

hey les gars, je suis d'accord avec vous, c'est sale de toucher aux auto_increment, mais avec un bemol:
desfois on est obligés de le faire

exemple vécu:
j'ai migré des données de différentes sources (une base access, des fichiers excel). pour les données de la base access,
- soit je laissais l'id en auto_inc et je devais bidouiller (= scripter) pour le retrouver pour les relations dans la suite de la migration (comment garder les relations si on a perdu l'id?)
- soit je gardais l'id et forçait le passage "manuel"/explicite des id
SET IDENTITY_INSERT entreprise ON
...
avant de le remettre en auto_increment:
SET IDENTITY_INSERT entreprise OFF
(sous SQL Server)

conclusion
parfois on peut toucher les id, si c'est la solution la plus adaptée (simplicité, temps de réalisation) mais en général on ne doit pas s'en soucier.

A+

Pascal

Je suis entièrement d'accord avec Cyrano !!!

On m'a toujours apris que dans une table, il fallait un identifiant auto_incrementé clé primaire et qu'il ne fallait jamais le toucher ni l'utiliser autrement que pour faire une clé étrangère !!!!

Cet identifiant doit être entierement invisible à l'écran, on ne doit jamais le modifier ou l'incrémenter !!!!

Ca permet de garantir une certaine intégrité référentielle et ça facilite énormément les modifications car tu as toujours un champs qui ne bouge pas !!!!

Je vais mettre un bémol là-dessus: mauvaise idée de gérer manuellement un champ de clé primaire: laisse donc faire MySQL. La clé primaire n'est pas une donnée, c'est un point de repère, point barre, il ne faut pas l'utiliser differemment. Ça permet de retrouver rapidement une donnée, de la mettre en relation avec les informations d'une autre table, mais ce n'est pas une donnée en rapport direct avec les données de la ligne correspondante.

Donc, si un champ est auto-incrémenté, c'est précisément pour ne pas à avoir à s'en soucier. Si tu as besoin d'un point de repère qui reflete le nombre d'articles dans l'ordre où ils ont été enregistrés, alors crée un champ supplémentaire en te disant qu'à chaque mise à jour ou modification de la table, il faudra mettre toute la colonne à jour pour chaque ligne si nécessaire.

C'est un peu inutile d«'autant qu'il y a des fonctions de tri qui te permettent de créer un numéro lors du traitement pour affichage, mais c'est un champ calculé que tu crées à la demande: par principe, on ne met JAMAIS de champ calculé dans une base. C'est un peu comme si on mettait une colonne "age" dans une table user. Les valeurs enregistrées dans cette colonne sont fausses dès le lendemain de l'enregistrement.

Ce n'est pas une bonne solution de donner des valeurs manuelle à une colonne auto_increment car il y a de très grande chance qu'il y ait conflit au moment ou on vas vouloir reprendre le cours des auto_increment !!!!

De manière générale, il ne faut pas mettre de valeur manuellement dans un champs auto_increment !!!

2 solutions :
- laisse le champs gérer tout seul les valeurs qu'il contient
- enlève le auto_increment et gère toi même les valeurs

Si tu supprimers le dernier enregistrement de ta table, le champ en auto_increment ne reviendra pas en arrière et ne reprendra pas à partir du dernier numéro existant mais du dernier numéro utilisé. Si le champ indque le plus grand à 4 et que le dernier à 5 a été supprimé, le suivant sera à 6 et non à 5 et on ne peut rien y faire sauf peut-être en forçant l'enregistrement du champ à 5 manuellement. (À tester, je n'ai pas vérifié)

Code:
SELECT MAX(auto_increment) FROM table


=> retourne 4, alors que l'auto_increment de la colonne auto_increment=5

donc le prochain enregistrement aurras comme comme id 6 et pas 5 comme mon code le laissait entendre.
En cas de jointure avec comme champs de reference la colonne auto-incrementée cela pose probleme si on y fait pas gaffe.
(dans le champs de reference de l'autre table jointe si je met la valeur du MAX +1 cela ne corrspondras pas)
Moralité je vais encore utiliser cette methode du SELECT MAX() mais apres y avoir introduit mes variables et avant de les introduirte dans le champs de la table jointe.
Guy[/code]

en même temps, connaitre la valeur actuelle de l'auto-increment, ça sert à quoi?

Strictement à rien.
Ce n'est pas la valeur de l'auto-incrément qui est intéressante,
mais le dernier enregistrement saisi dans la table
(auquel correspond cette valeur de l'auto-incrément)
et je crois que c'est ça que recherche Guy.