Pour avoir essayé des choses similaire, je peux te dire que le probleme que tu poses risque de bloquer à cet endroit :
Lorsque l'on envoie une donnée à travers le réseau, elle passe. Si on en envoie beaucoup, elles arrivent aussi à passer. Mais lorsque l'on en envoie trop, elles arrivent déformées, voire même n'arrivent pas du tout.
Au dela de 3 pages de formulaire, tu n'as aucune chance de faire passer tes variables. Il y aura le poids de la page plus le poids des données, ca ne passera pas, tout simplement.
Ce n'est pas possible de faire passer autant d'informations d'une page à une autre. Il faut donc se tourner vers une autre solution.
Bon. Il y a plusieurs facons de faire :
- Tu stocke dans une base de données toutes les informations, jusqu'à la dernière page, et tu traites les informations à la fin, comme s'il s'agissait d'un seul formulaire. Mais il y a le risque que les personnes arretent en cours de chemin, et donc tu te retrouves avec une base à vider de temps en temps, etc. Il y a le risque que, à force de faire des 'aller et retour' entre les pages, tes données finissent par devenir 'n'importe quoi' dans la base, et ce n'est pas la bonne solution non plus.
- Tu sépares ton formulaire en groupes de données logiques, et tu fais remplir ces groupes de données, les uns à la suite des autres. Un formulaire, une fois rempli, est 'inséré' dans la base, et c'est tout. Meme si la personne retourne dessus.
La seconde solution est la plus préférable. Pour ce qui est de l'insertion dans la base de données, et du bouton 'précédent', il faut se rappeler ceci : Lorsque tu envoies un message dans le forum du Hub, par exemple. Si tu fais 'retour', le message est envoyé, tout simplement. Tu reviens bien dans la page 'répondre', mais il est trop tard, la page est déjà envoyée. Limites donc l'utilisation du bouton 'retour', et javascript 'history'.
La facon de faire est donc simplifiée. Tu sépares les données à remplir via ton formulaire, par exemple, comme ceci :
Plan des tables :
VILLE
id_ville
HOTEL
id_hotel
id_ville
CHAMBRE
id_chambre
id_hotel
SERVICES OFFERTS
id_services
HOTEL_SERVICES
id_hotel
id_services
Commences par la table ville. Tu récupères l'id_ville, qui te permettra de remplir 'hotel'. Ensuite, tu remplis 'hotel'. Tu récupères l'id de hotel. Tu as tous les éléments pour faire 'chambres', donc tu fais 'chambres'.
Pour ce qui est des tables jointures, tu t'en occupes lorsque tu as tous les éléments pour le faire, à savoir : id_hotel, id_services, que tu auras gardé jusqu'à la fin.
A la fin du formulaire, tu peux lancer une vérification des tables, pour voir si les tables sont bien 'jointes' les unes aux autres.
Mais, d'une manière générale, avec ce système, tu ne peux pas avoir d'erreurs. Au pire, tu auras une ville sans hotel ? Un hotel sans chambres ? Lors de la vérif, ce ne sera pas difficile à controler.
Bon.. Cet exemple est trivial, c'est pour te montrer ce que c a peut donner, il est vrai que ce n'est jamais pareil, et que ca dépend aussi si l'on s'adresse, via cette interface, au public ou à la partie 'admin'.
Juste une petite chose :
CITATION
Pour effectuer les mises a jour dans ma BDD, (l'utilisateur clique sur la fleche precendent) n'est-il pas plus simple de recuperer l'enregistrement(s), de l'afficher a l'ecran, d'effacer l'enregistrement(s), puis lorsque l'utilisateur clique sur suivant de recreer un nouvel enregistrement? Quel est interet de "update" en mysql?
N'effaces pas ! Imagines qu'un autre enregistrement ait besoin de cet enregistrement !
Imagines que le client fait tout le formulaire, et cliques une dizaine de fois sur le bouton 'précédent'. Il devrait se retrouver sur la page d'accueil, sans n'avoir demandé d'effacer ses enregistrement, or ils ne seront plus là

Voilà, en espérant t'avoir aidé

Anonymus.