@AB
C'est bien sûr, on peut tout mettre ça dans PHP par la suite. Pour l'instant, il suffit d'établir et de tester la requête.
Ensuite, plutôt que de passer par une table en CSV, je crois qu'il sera possible d'exporter directement au format Excel.
Une fois la requête bien établie avec PhpMyAdmin, il suffira de copier/coller cette requête dans le code PHP.

Aussi, passer par PhpMyAdmin parce que c'est ce qu'il fait actuellement.
Veut-il se lancer dans la programmation PHP et tout automatiser immédiatement ou ne veut-il que passer ses données une fois par années ?
Je dirais qu'à raison d'une fois par année, ça ne vaut pas la peine de bâtir du code, de le déboguer, de l'intégrer dans un programme et d'ajuster le tout.
Le besoin exprimé, jusqu'ici, n'est qu'un transfert de données. Je ne veux donc pas imposer au banqet à qui demande café/roties.

Heu... j'ai pas compris la même chose :

j'ai créé un formulaire de saisi en php qui à l'aide d'un bouton "envoyer" transfert toutes les données saisies dans une table de ma base phpmyadmin.
Ma question est la suivante:

Peut-on à la fois envoyer les informations saisies dans ce formulaire dans la base de données sql et dans une base de données access se trouvant par exemple sur mon serveur (MUTUALISE)...?

Donc
1/ Si les données saisies par ce formulaire sont suffisantes pour alimenter un tableau excel exploitable par word, on peut les ajouter directement au fichier excel : on ouvre le fichier avec l'option "a" et on utilise fputcsv pour ajouter les données à la suite du fichier.
2/ Sinon après avoir inséré les données dans mysql, on fait une requête complémentaire pour avoir les données nécessaires au format CSV et on peut toujours utiliser fputcsv pour insérer le résultat de la requête à la suite du fichier CSV. Dans mon exemple il suffit de faire @fopen($dirfile, 'a') à la place de @fopen($dirfile, 'w')

T'as raison, j'en avais oublié le début de la discussion.

À mon avis, la base de données doit aussi servir à autre chose qu'à ce seul formulaire. Ta solution, AB, permettrait de tenir à jour les deux bases de données par le formulaire, mais tout autre changement aux informations nécessiterait aussi une double intervention (mysql et csv). Ce n'est pas évident à faire dans le CSV losrsqu'il s'agit de modif. Il me semble préférable - et plus souple pour les développements à venir - de ne maintenir à jour que la base MySQL et l'exporter en CSV au besion, chaque fois qu'il sera nécessaire de faire un publipostage.

Reste à orell1 à nous dire s'il veut simplement récupérer les données en double (MySQL et CSV) comme AB le propose en une seule étape ou conserver les données en MySQL puis le récupérer en CSV en deux étapes comme je le suggère.

À toi orell1

C'est à dire que je conçois la définition du schéma de fonctionnement au plus simple en considérant que les choses ne sont pas encore figées. Si la table excel (et c'est ce que j'ai pensé en première lecture) ne sert que pour faire un mailing avec word, alors la solution que j'ai donnée est la plus pratique car automatique et transparente. Quand on veut faire un mailing, il suffit de le faire à partir du fichier CSV créé et qui est mis à jour en continu.

Remarque que ma solution n°2 ne fait pas une copie "en double" comme tu le dis mais va chercher les informations nécessaire dans les autres tables pour compléter le fichier csv tel qu'il doit être pour le publipostage.

La seule contrainte comme tu l'a souligné est qu'il ne faut pas rentrer des données autrement que par l'intermédiaire du formulaire de saisie. Mais en même temps d'être une contrainte c'est souvent une nécessité et une sécurité : comment aller bidouiller dans une bbd une dizaine de tables (dans le cas d'enregistrement d'un produit par exemple) pour aller ajouter un enregistrement ? Seul l'emploi du formulaire de saisie garanti l'intégrité des tables. Suffit juste de concevoir le cms qui va bien et qui sera aussi simple d'emploi que de remplir un tableau excel.

Donc j'utiliserais cette solution, tout automatique et donc gérable par tout le monde (cad un administrateur ayant le minimum de droits), comme le fonctionnement par défaut, et si besoin j'utiliserais ta solution en complément (au cas où des enregistrement seraient rentrés en dehors du formulaire) et qui serait donc accessible uniquement par un responsable technique ou le webmestre

Bonjour,

alors grande nouvelle! j'ai réussi!
en fait qu'on on y réfléchi c'est très simple! j'ai tout fait à partir de phpmyadmin.

Il fallait que je récupère des informations contenu dans 3 tables ayant pour point commun le champs "num_client"
en partant de la j'ai exporté depuis phpmyadmin mes 3 tables au format excel 2007...
J'ai créé sous access une base de données puis j'ai importé mes trois bases excel en faisant une indexation et une clé primaire avec num_client, de cette façon mes 3 bases ont été relié par le même champs.
Ensuite j'ai créé une requête en liant les 3 clés primaires, puis j'ai selectionné les champs à fusionner... puis j'ai exécuté la requête !

RESULTAT: UN TABLEAU PARFAIT, avec un croisement de données impeccable ! ouf! je pensais vraiment que j'allais devenir fou!
En tout cas UN GRAND merci à vous d'avoir eu la gentillesse de bien vouloir m'aider!

Petite question dans ma base sql mes mes dates s'affiche sous cette forme "1305835666" et non sous la forme "00/00/0000" donc cela se répercute dans mes exportations donc je ne peux pas classer par date.
voici un morceau de ma table:

`date_limite` int(11) NOT NULL, 

cette date est générée automatiquement par mon formulaire de saisie
EXEMPLE: je remplie mon formulaire de saisi aujourd'hui la date limite sera donc : 01/10/2011.

Merci par avance

Ce numéro est vraisemblablement un "timestamp", c'est une valeur représentant la date et l'heure.
Tu peux donc l'utiliser directement pour trier tes champs, ce sera un tri par date et heure.
En PHP, tu peux facilement transformer cette valeur à l'aide de la fonction date ainsi: date("d/m/Y", $valeur)
Consulte http://ca2.php.net/manual/fr/function.date.php au besoin
Access présente certainement un moins de conversion aussi. Autrement, tu peux le calculer toi-même, 0 étant le 1969-12-31 17:00:00, un est additionné à chaque seconde.
La valeur soumise correpond donc au 2011-05-19 14h07:46, soit le 19 mai 2011 à 14 heures 7 minutes et 46 secondes

Effectivement tu as raison c'est "timestamp"....
Je vais voir si access ou excel peuvent me convertir cela...?

Merci encore!

Tu peux le faire convertir par ta requete SQL comme ceci:

SELECT CONCAT(DAY(`date_limite`),'/',MONTH(`date_limite`),'/',YEAR(`date_limite`)) AS DateEcriteEnJourMoisAnnee FROM pefac_entreprises_dossier

Te référer à : http://dev.mysql.com/doc/refman/5.0/fr/ ... tions.html

Super Merci!
je vais essayer tout ça!