Vous n'êtes pas identifié(e).
Pages : 1
Merci mais vous pouvez en conseiller un en fonction de votre expérience ?
Après avoir lu l'article en deux parties de Nathan Matias, j'ai l'impression qu'il est préférable de faire la migration à la main.
Ca oblige de revoir SQL, moi qui ait été élevé avec MySQL !
Merci mais ça à l'air d'être bien compliqué ...
Pourquoi les outils de migration ne font pas ça !
Dans mysql j'ai:
CREATE TABLE `membres` (
`Id_Membre` int(10) NOT NULL AUTO_INCREMENT,
...
PRIMARY KEY (`Id_Membre`)
) ENGINE=InnoDB AUTO_INCREMENT=191 DEFAULT CHARSET=latin1 ROW_FORMAT=FIXED;
Que je traduis par:
CREATE TABLE membres
(
id_membre serial not null,
...
primary key( id_membre)
)
Après la migration, comment indiquer qu'id_membre devra prendre la valeur 191 lors d'une insertion ?
Quel(s) produit(s) utilisent en général les membres de ce forum ?
Bonjour,
J'ai utilisé kettle pour migrer une base mysql/innodb en postgresql (note: je suis débutant).
Dans mysql j'ai:
CREATE TABLE `membres` (
`Id_Membre` int(10) NOT NULL AUTO_INCREMENT,
...
PRIMARY KEY (`Id_Membre`)
) ENGINE=InnoDB AUTO_INCREMENT=191 DEFAULT CHARSET=latin1 ROW_FORMAT=FIXED;
J'obtiens:
CREATE TABLE membres
(
id_membre integer,
...
)
NOT NULL a disparu pourtant cela semble exister en postgresql
AUTO_INCREMENT a disparu: le type serial existe en postgresql
la clé primaire a disparu
191 a disparu
Est-ce du aux majuscules ? Id_Membre
Kettle n'est pas le bon produit ? faut-il le paramétrer ?
Merci
Merci pour votre aide.
oui oui oui !
Je pense qu'il y a une règle quelque-part qui empêche psql -h hostname, j'ai la même chose avec Mysql -h hostname, donc cela ne m'inquiête pas trop même si cela n'est pas propre.
Je viens de relancer le service postgresql-9.1 et cela remarche. J'ai fais plusieurs tentatives (<f5> pour rafraichir la page html contenant le script php) et cela marche toujours.
La relance du service a débloqué quelque-chose ? A part le fichier log, que peut-on analyser ?
La base de données n'existe que de nom (rappel: je débute ...).
J'ai remis l'arobase et cela ne fonctionne plus puis j'ai enlevé l'arobase et ... cela ne fonctionne plus :-(
Je n'y comprend plus rien.
Voilà le log chez l'hébergeur:
[Sun Sep 16 18:11:35 2012] [error] [client xxxxxxxxxxx] PHP Warning: pg_connect() [<a href='function.pg-connect'>function.pg-connect</a>]: Unable to connect to PostgreSQL server: could not connect to server: Connection timed out\n\tIs the server running on host xxxxxxxxxxxxxxxxx and accepting\n\tTCP/IP connections on port 5432? in xxxxxxx
Voilà les derniers messages dans mon log:
2012-09-16 17:31:37 CEST LOG: connexion reçue : hôte=xxxxxxx port=42503
2012-09-16 17:31:37 CEST LOG: connexion autorisée : utilisateur=postgres, base de données=postgres
2012-09-16 17:31:37 CEST LOG: déconnexion : durée de la session : 0:00:00.235
utilisateur=postgres base=postgres hôte=xxxxxxx port=42503
Cela donne l'impression que postgresql se "bloque" de mon côté !
Alors là je tombe des nues ...
J'ai enlevé l'arobase devant pg_connect et ça passe !
Avez-vous une explication ? Est-ce une erreur chez l'hébergeur ? Un paramètre qui manque ?
Dans le cas où pg_connect retourne false j'ai voulu tester pg_last_error mais cette fonction retourne rien ! mauvaise méthode ?
L'adresse est bien sur l'adresse privée. Je fais des tests avec. Le serveur est derrière un router et un modem qui fait du NAT. L'adresse public est celle que j'ai appelée "adresse_ip_de_mon_serveur_windows_2003", celle figurant dans la commande pg_connect du script php situé sur une machine d'un hébergeur (héberge mon application web). Le serveur 2003 est chez moi. J'espère que c'est plus clair maintenant.
nmap -v adresse_ip_de_mon_serveur_windows_2003 -sT -p 5400-5500 répond que les ports sont filtrés. Je ne maîtrise pas cet outil :-(
La règle du firewall est: autoriser TCP ou UDP entrant/sortant depuis MAC Tout vers MAC Tout où le port source est Tout et le port de destination est 5432, une seconde règle autorise Tout sur Tout en sortie.
Pourquoi cela passe avec Mysql ?! J'ai copié les règles et changé 3306 en 5432 !
J'ai testé avec shieldUP! le NAT: est-ce suffisant pour dire que ca marche ?
Le FW dit que Postgres écoute sur 5432: est-ce suffisant pour dire que ca marche ?
Auriez-vous d'autres tests à me suggérer ?
Peut-on tracer plus de choses qui pourraient m'aider avec Postgresql ?
Variables d'environnement ? A part le path vers /bin ?
Je viens de faire nmap -v 192.168.1.100 -sT -p 5400-5500
J'obtiens 5432/tcp open postgresql
Je viens de faire netstat -a -p TCP
J'obtiens TCP dev:5432 dev.dev.local:0 en ecoute
- j'ai fait pg_connect seulement. L'erreur est extraite du log de l'hébergeur.
- psql -h ... donne connection timeout (0x00002746/10060)
- depuis le serveur php je ne sais comment faire
merci,
could not access ... est le message. Le timeout est long
la ligne est bien décommentée. elle l'est par défaut dans la version 9.1.4
j'ai relancé plusieurs fois le service également
Bonjour,
D'abord je dois dire que c'est la première fois que j'essaye d'utiliser postgresql: soyez indulgent !
J'ai installé sur un serveur windows 2003 la version 9.1.4 de postgresql.
Depuis une application PHP située chez un hébergeur j'essaye d'accéder à une base de données mais rien n'y fait (could not access ...).
- l'hébergeur supporte postgresql vers l'extérieur
- dans le fichier postgresql.conf, j'ai bien listen_addresses='*'
- dans le fichier pg_hba.conf, j'ai rajouté au début host all all 0.0.0.0/0 md5
- avec pgadminIII, j'ai crée une base de données test, owner = postgres
Mon application PHP ne fait que pg_connect("host=adresse_ip_de_mon_serveur_windows_2003 port=5432 dbname=test user=postgres password=pw_de_postgres")
- avec shieldUP! j'ai testé que le port 5432 est bien ouvert et le NAT correct
- mon firewall affiche postgres.exe listen on 5432
- depuis cmd.exe, sur le serveur, si je fais psql -U postgres test, j'obtiens test =#
Ai-je oublié quelque-chose ?
merci
Pages : 1
