Gestion d'un extranet particulier ?

[cavo789]

Tu es sacrément tenace !

Bon amusement !

[RobertG]

En effet !
Je l'aurai ! (pas encore, je galère pour copier les lignes avec pg_copy_to)

[lefabdu51]

bonjour tout le monde.. Perso, pour les formulaires multi pages, j'utilise chronoforms. C'est le plus simple et il permet de gérer chaque page de ton formulaire indépendament les unes des autres.

Pour ce qui est de la migration postgres vers mysql, le plus simple est un export dans un fichier .sql de la base postgres, suivi d'un import dans la base mysql .
Si tu a l'accès au serveur postgress directement, tu peux le faire via la commande pg_dump.
Remplace mabdd par le nom de la base de données à copier .

sudo -u postgres pg_dump --format p --inserts mabdd > /chemin/fichier.sql

Une fois l'import mysql fait, pense à créer tes utilisateurs sql et à leur attribuer des droits.

[RobertG]

Bonjour,

Je l'ai eue !

Grâce à "pg_copy_to", J'ai un export des données, table par table (pour le moment testé seulement sur la première avec un die() en fin de boucle), les données au format csv. Le fichier, dont le nom est daté, est bien généré, et comme d'habitude, Excel ne reconnaît pas l'UTF-8... alors que notepad++ l'affiche bien.

Cette fonction n'exporte pas les entêtes, il faut que je trouve comment le faire avant la copie.

Mon problème est aussi de trouver le bon séparateur de champs : en analysant la sauvegarde SQL je vois que les virgules et points-virgules sont nombreux, je trouve un "|" dans une adresse d'utilisateur...

Il faut aussi que je comprenne pourquoi j'ai systématiquement une ligne vide entre deux lignes de données.

[RobertG]

Merci lefabdu51, mais d'abord la ligne de commande, comme déjà dit, ce n'est pas pour moi , ensuite avec un SQL comme j'ai cité plus haut, sans séparateur clair (pour moi) et provenant d'OVH, si PostgreSQL sait importer ses propres sauvegardes, je ne suis pas sûr que MySQL le sache.
De plus, la structure des tables que j'utiliserai dans Joomla! ne sera pas nécessairement la même (import des élèves par exemple, comme utilisateurs ou dans une table distincte, et il y en a un très grand nombre), ce qui nécessitera de gérer la correspondance des champs avant import.

[RobertG]

J'ai réussi à inscrire la liste des champs en première ligne.
Avec pg_copy_to j'ai toujours ces lignes vides entre deux lignes de données, je ne comprends pas pourquoi.

$array = pg_copy_to($pg, $tablename, "~",'');      
$contents = implode("\n", $array);
fwrite($head, $contents);
​

Il m'a fallu utiliser une fonction de suppression de ces lignes vides de $contents avant d'écrire.
Avec une autre fonction de lecture puis écriture que pg_copy_to, je perdais la valeur du dernier champ.

En revanche, j'ai un truc bizarre : le script veut absolument écrire le fichier sur mon PC, en plus de celui sur le serveur...

[RobertG]

Bonsoir,

J'ai un os : bien que la requête passée utilise "order by id", la fonction pg_copy_to n'en tient pas compte, il faudrait que je revienne à celle qui me perdait le dernier champ de chaque ligne (et dont je n'ai pas conservé le code).
Y aurait-il une solution a posteriori pour reclasser des lignes de ce type sur leur id ?

id,name,description,price,weeks,active
97,Special course 20 hours/week,,490.00,1,f
79,DUO Children,pour les jeunes enfants quand ils sont 2 : 300€ soir 150€ chacun,150.00,1,f
49,Kids creative workshops 4/10yo (6hours/Day), 6 heures de 10h a 14 h,400.00,1,f
86,Kids creative workshops 4/10yo (4 hours/day),,250.00,1,f

Merci de vos conseils !

[cavo789]

Hello

Je te lis sans trop savoir te dépanner puisque perso j'aurais opté pour la console. Tu parles d'une fonction pg_copy_to dont j'ai zéro connaissance (et donc jamais utilisé).

Ta remarque m'étonne toutefois : ton but est de générer un dump pour récupérer les données dans mysql si j'ai bien compris. Dans ce cas, l'ordre des lignes lors de la sauvegarde est absolument non pertinent puisque "order by id" n'a d'utilité que lorsque tu vas faire un query sur la table mysql. C'est-à-dire qu'on se moque de savoir si les données, dans la table, sont triées ou pas, cette notion n'a pas de pertinence au niveau de la sauvegarde (si toutefois je comprends bien ton os).

(juste pour info, pgloader est un outil qui permet de migrer de mysql vers postgresql, peut-être un autre outil existe dans l'autre sens mais c'est une fois encore de la console)

[RobertG]

Merci Christophe,

En fait, j'ai déjà importé lors d'activités précédentes une partie des données. Depuis d'autres ont été ajoutées, et je voudrais pouvoir vérifier ce qui est nouveau, chose impossible puisque les fichiers que j'obtiens sont en désordre (déjà dans la base PostgreSQL, ce qui m'étonne).
Mon code après insertion dans le fichier de l'entête liste des champs est :

            $array = pg_copy_to($pg, $tablename, ",");      
            $contents = implode("\r\n", $array);
            $contents = retirelignesvides($contents);
            fwrite($head, $contents);            
​

$array récupère les lignes, puis elles sont traitées pour supprimer les lignes vides et écrites dans le fichier, dans 'ordre où elles o,nt été trouvées.
Tu m'avais un jour conseillé ksort pour trier une liste de fichier dont le premier champ était numérique. Ici, le problème est que la première ligne commence par "id" puisque c'st la liste des champs. Il faudrait donc que j'arrive à trier uniquement la partie données avant de l'écrire dans le fichier.
Un simple ksort($contents) suffirait-il sachant que le tri se fait sur le premier champ ?

[cavo789]

Dans ton post 22 ci-dessus tu produits quelques lignes. Est-ce le contenu de ton ficher après fwrite ? Est-ce fichier que tu aimerais trier sur la colonne id ?

Garder la première ligne de titre puis les données triées...

[RobertG]

J'écris d'abord les noms des champs, puis je récupère les lignes de la base avec pg_copy_to qui les met dans le tableau $arrays avant dele traiter et d'écrire.
J'avais testé avec sort et ksort sur $contents, à tort. Cela fonctionne à moitié avec $array qui est le tableau ! En effet, le tri par sort me place la ligne 4 après une ligne 34 et une ligne 7 après 64, prenant le premier chiffre et pas le champ lui-même

[RobertG]

Trouvé, à vérifier sur d'autres tables

sort($array, SORT_NUMERIC);

semble être la solution.

[cavo789]

Une idée à un eurocent : ton pg_copy, c'est une commande que tu as lancé sur une table ? Si tu crées une vue qui elle est triée sur le champs ID puis pg_copy de la vue; ce serait bon non ?

[RobertG]

C'est ce que j'avais essayé suite à l'étude des avis d'utilisateurs sur pg_copy_to dans le manuel PHP mais ça n'a pas fonctionné, peut-être parce que j'ai fait une erreur.

[RobertG]

Je viens d'essayer cette syntaxe proposée sur la page pg_copy_to du manuel PHP

$array = pg_copy_to($pg, "select * from ". $tablename . " order by id", ",");

mais aucune donnée n'est récupérée, le tableau est vide.
Alors que ceci fonctionne bien.

$array = pg_copy_to($pg, $tablename, ",");

Je reste donc à mon code avec sort().

Je suis toujours dans l'expectative en ce qui concerne le séparateur CSV, dans la mesure où la virgule, le point virgule et tous les caractères spéciaux sauf le tilde sont déjà présents dans les données.

Avant d'aller plus loin, il va me falloir attendre la validation du formulaire (multi-onglets) et autres fonctionnalités afin d'être sûr de ne pas devoir changer la structure des tables, que j'avais définie il y a trois ans (et non deux, j'ai rectifié plus haut) à partir de la copie de base PostgreSQL que j'avais pu faire chez PlanetHoster et examiner avec phpPgAdmin.