PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 Re : Migration » problème de droit sur pg_class pour runMTK » 16/05/2014 13:11:44

Je crois que j'ai réussi :

perl -MCPAN -e shell
get DBD::Oracle
quit

cd /home/Xavier/.cpan/build/DBD-Oracle-1.74-Vp3xUv/
perl Makefile.PL
......
OCI directory not found, please install OCI in /cygdrive/c/Program Files/Common Files/Microsoft Shared/Windows Live at Makefile.PL line 324.


ORACLE_HOME=/cygdrive/c/app/Xavier/product/11.2.0/dbhome_1/
export ORACLE_HOME

perl Makefile.PL
....

make
...........
/bin/sh: gcc-4 : commande introuvable
Makefile:407: recipe for target 'Oracle.o' failed
make: *** [Oracle.o] Error 127

ln -s /usr/bin/gcc.exe /usr/bin/gcc-4
ln -s /usr/bin/gcc.exe /usr/bin/g++-4

make 
....

make install
...

Ca a l'air ok, mais j'ai des problème de conf Oracle à régler (SID).

#2 Re : Migration » problème de droit sur pg_class pour runMTK » 15/05/2014 16:56:19

En fait non ...
J'ai mis un fichier de conf et ora2pg donne :
Can't locate DBD/Oracle.pm
Sauf qu'il n'y a pas de package tout préparé comme pour d'autres produits dans cygwin ...

#3 Re : Migration » problème de droit sur pg_class pour runMTK » 14/05/2014 10:23:32

bonjour,

En fait, j'avais déjà Cygwin installé sur ma machine. Site à vos remarques, j'ai regardé dans la liste des packages disponibles, ora2pg n'y est pas (dommage), mais dans la cathégorie databases, je vois perl:DBI (il est aussi accessible depuis la cathégorie perl). Je l'ai installé, et plus d'erreur :-)
Enfin, je ne l'ai pas encore utilisé pour transférer des données, mais au moins, quand je tape ora2pg, j'ai bien un rappel de l'usage.
Donc, pour ceux que ça interresse de faire fonctionner ora2pg avec cygwin, c'est très simple :
installer cygwin avec make (qui n'est pas par defaut !), perl et perl:DBI.
Puis les commandes pour unix/linux :

            tar xzf ora2pg-10.x.tar.gz
            cd ora2pg-10.x/
            perl Makefile.PL
            make && make install

#4 Re : Migration » problème de droit sur pg_class pour runMTK » 28/04/2014 14:25:24

Je n'ai pas réussi à installer correctement ora2pg.
Je suis sous windows avec Cygwin.
les commandes d'installation perl, make && make install se sont correctement déroulées, mais quand je lance ora2pg, j'ai l'erreur :

Can't locate DBI.pm in @INC (@INC contains: /usr/lib/perl5/site_perl/5.14/i686-cygwin-threads-64int /usr/lib/perl5/site_perl/5.14 /usr/lib/perl5/vendor_perl/5.14/i686-cygwin-threads-64int /usr/lib/perl5/vendor_perl/5.14 /usr/lib/perl5/5.14/i686-cygwin-threads-64int /usr/lib/perl5/5.14 /usr/lib/perl5/site_perl/5.10 /usr/lib/perl5/vendor_perl/5.10 /usr/lib/perl5/site_perl/5.8 .) at /usr/lib/perl5/site_perl/5.14/Ora2Pg.pm line 29.
BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.14/Ora2Pg.pm line 29.
Compilation failed in require at /usr/local/bin/ora2pg line 30.
BEGIN failed--compilation aborted at /usr/local/bin/ora2pg line 30.

Du coup, je n'ai pas eu envie de me battre avec ça. J'ai mis les droits à mon utilisateur, et jai utilisé l'outil que j'avais trouvé au début ...

#5 Re : Migration » problème de droit sur pg_class pour runMTK » 24/04/2014 14:00:55

J'ai ça :

2014-04-24 13:58:03 CEST ERREUR:  droit refusé pour la relation pg_class
2014-04-24 13:58:03 CEST INSTRUCTION :  update pg_catalog.pg_class set relhasindex = 'f' where oid = 'monschema.table3'::pg_catalog.regclass

#6 Re : Migration » problème de droit sur pg_class pour runMTK » 24/04/2014 11:21:53

Merci, mais je viens de regarder un peu, et je ne suis pas sur que l'outil soit en cause. En fait, c'est un et un seul champ qui me pose problème : j'ai dans Oracle un champ de type raw.
L'outil m'a créé une table pg avec ce champ au format bytea.
Mais j'ai l'erreur lors du transfert des données.
Est ce qu'il y a des difficultés particulières à manipuler des champs binaires ?

#7 Re : Migration » problème de droit sur pg_class pour runMTK » 24/04/2014 09:54:06

Ah, pardon, pardon ;-)

En fait, quand j'ai cherché un outil de transfert de données d'Oracle vers pg, j'ai de suite trouvé EnterpriseDB Tools sur http://www.enterprisedb.com. Comme c'est simple et gratuit, j'ai pensé que c'était l'outil de référence que tout le monde utilise.
Je vois que non.
Alors quel est l'outil le plus simple de transfert qui serait l'outil de "reférence" ?

#8 Re : Migration » [] smallint en paramètre in out d'une fonction » 24/04/2014 09:42:26

Et bien ... Parce que je ne savais pas que l'on pouvait faire comme ça.
En effet, ça fonctionne très bien, et là, c'est propre ;-)
Merci !

#9 Migration » problème de droit sur pg_class pour runMTK » 23/04/2014 16:04:43

Xav1er
Réponses : 16
runMTK.bat -tables TABLE1,TABLE2 -dataOnly monschema

-> ok

runMTK.bat -tables TABLE3 -dataOnly monschema

-> ko :  ERREUR: droit refusÚ pour la relation pg_class

Comment je peux avoir l'erreur pour une table et pas pour d'autres ?
Comment corriger ce problème ?

#10 Re : PL/pgSQL » utilisation d'un tableau à 2 dimentions en pgsql » 23/04/2014 15:29:55

CREATE OR REPLACE FUNCTION montest(test character varying)
  RETURNS void AS
$BODY$
DECLARE 

	montab smallint [3][4];
	
BEGIN
	montab[0][0]:=3;
	montab[0][1]:=4;
	montab[2][1]:=5;
	montab[2][2]:=6;
	raise notice 'Valeur : %', montab[2][1];

	return;
END ;
$BODY$
  LANGUAGE plpgsql VOLATILE
  COST 100;



select montest('toto');



ERREUR: indice du tableau en dehors de l'échelle
État SQL :2202E

#11 Re : Migration » [] smallint en paramètre in out d'une fonction » 23/04/2014 15:17:23

Au cas où ça peut aider d'autres personnes, ma problématique était d'écrire une fonction avec plusieurs paramètre inout dont au moins 2 doivent être récupérés avec la syntaxe * comme expliqué par gleu plus haut.
Je n'ai pas réussi à trouver une syntaxe avec un "select" qui fonctionne.
Pour contourner, j'ai créé une table vide avec tous les champs que je voulais (dont 2 de type smallint []).
J'ai créé une variable Var_table MATABLE;
et en faisant VAR_table := ma_fct (var1, Var2, VAR_table);
Ca fonctionnne.
Je ne trouve pas ma solution très propre parce que j'ai créé une table vide juste pour avoir une liste de champs, un peu comme pour définir une structure en C, mais c'est la seule que j'ai trouvée ...

#12 PL/pgSQL » utilisation d'un tableau à 2 dimentions en pgsql » 15/04/2014 14:54:37

Xav1er
Réponses : 2

J'essaie d'utiliser un tableau à 2 dimentions

montab  smallint [][];
...
	montab[0][0]:=3;
	raise notice 'montab 00: %', montab[0][0];	
	montab[1][3]:=4;

Pour le 0 0, c'est ok, ça affecte ...
Pour toute autre affectation, j'ai l'erreur :

ERREUR: indice du tableau en dehors de l'échelle
État SQL :2202E
Contexte : fonction PL/pgsql pnt.p_test3(character varying), ligne 25 à affectation

Comment utiliser un tableau à 2 dimentions ? Faut-il l'initialiser ?


Et si je crée une fonction où un des paramètres est smallint [][], pg me l'enregistre comme smallint [].
Est ce que c'est normal ?

#13 Re : Général » psql sous Cygwin » 14/04/2014 13:10:06

Ce week-end, j'ai essayé le psql qui s'installe avec cygwin, il fonctionne très bien.
Apparemment, le pb de la version 7 ne se pose plus avec la version 9.

#14 Re : Général » psql sous Cygwin » 09/04/2014 13:33:48

Je vais avoir l'air de dépoussiérer le sujet, mais est ce que cette manipulation est supposée toujours fonctionner ?
J'ai essayé

cp /cygdrive/c/Program\ Files/PostgreSQL/9.3/bin /usr/bin/
./psql.exe -h localhost -p 5432 --username=monuser --dbname=mabase
/usr/bin/psql.exe: error while loading shared libraries: LIBPQ.dll: cannot open shared object file: No such file or directory

Quand j'essaie dans l'emplacement de program files, ça freeze.

Sur internet, certains sites disent qu'il faut recompiler, d'autres mettre pg sous forme de service ...
Comment faire fonctionner psql version 9.3 sous cygwin ? Si possible sans recompiler ...

#15 Re : Général » Fonctionnement des timestamp et fuseaus horaires » 04/04/2014 16:24:37

Il y a ça aussi que je trouve mieux :

select ('2014-04-01 12:30' at time zone 'Indian/Reunion') at time zone 'Europe/London';

#16 Re : Général » Fonctionnement des timestamp et fuseaus horaires » 04/04/2014 15:29:10

Ca y est, j'ai trouvé ;-)

select '2014-04-01 12:30 Europe/London'::timestamptz at time zone 'Indian/Reunion';

Et je vais pouvoir remplacer les zones en dur par des données provenant de champs de mes tables smile

#17 Re : Réplication » problème de droit pour utiliser pg_dump » 04/04/2014 14:43:29

J'ai trouvé mon problème : mon utilisateur était propriétaire du shéma mais pas des tables (c'était postgres).
Maintenant, ça fonctionne ;-)

#18 Re : Général » Fonctionnement des timestamp et fuseaus horaires » 04/04/2014 13:58:25

Il n'y a pas moyen de faire tout dans la même requête ?
Je trouve ça très contraignant de changer ce paramètre par ce que c'est une requête qui est dans une boucle.

set timezone to 'xxxxx/xxxxx';
traitement
set timezone to 'Europe/Paris';

En plus, dans un select, je ne peux pas sélectionner des occurences qui ont une heure locale entre 12h et 14h, par exemple. J'ai un champ avec un timestamp without timezone, avec heure convertie à l'heure de Paris, et un champ avec le fuseau horaire d'origine.

#19 Général » Fonctionnement des timestamp et fuseaus horaires » 03/04/2014 15:21:12

Xav1er
Réponses : 4

Bonjour,

J'ai du mal à comprendre le fonctionnement des timestamps.

Par exemple, comment faire pour savoir quelle heure il est à la Réunion quand il est 12h30 à Londres ?
Les requêtes que j'ai essayées ne donnent pas le bon résultat.

Sous Oracle, je pouvais faire :

select 
to_char (CAST(FROM_TZ(CAST(to_date ('20140102123000','YYYYMMDDHH24MISS') AS TIMESTAMP), 'Europe/London') 
AT TIME ZONE 'Indian/Reunion' AS DATE),'YYYYMMDD HH24MISS') from dual;

Qui donne bien 16h30 en hiver. Je ne parviens pas à faire l'équivalent en pgsql ...

#20 Réplication » problème de droit pour utiliser pg_dump » 03/04/2014 14:41:21

Xav1er
Réponses : 3

Bonjour,

Je n'arrive pas à utiliser pg_dump
J'ai le message d'erreur :
pg_dump: [programme d'archivage (db)] échec de la requête : ERREUR:  droit refusé pour la relation xxx
pg_dump: [programme d'archivage (db)] la requête était : LOCK TABLE "XX".xxxIN ACCESS SHARE MODE

Je ne comprends pas pourquoi j'ai cette erreur parce que j'utilise le role qui est propriétaire du shéma ...

#21 Re : Migration » [] smallint en paramètre in out d'une fonction » 30/01/2014 12:08:56

Pour le smallint [] en INOUT avec plusieurs paramètres, ça fonctionne en le récupérant avec *, comme pour un champ de type character varying.

Plus que le champ modifié de type ROWTYPE à récupérer, et j'aurai tous les éléments pour voir si mes procédures et fonctions Oracle sont adaptables sous pgsql ...

#22 Re : Migration » [] smallint en paramètre in out d'une fonction » 30/01/2014 11:33:24

Ah, oui, comme ça, ça fonctionne.
On progresse, mais j'ai un nouveau problème.
Ma fonction Oracle avait plusieurs paramètres IN OUT en entrée dont 1 de type ROWTYPE.

Et si j'essaie un :

select into RW$TEST , LC$VAR4 from select titi.test4 (0, 1 ,RW$TEST , LC$VAR4);

avec les 2 derniers en INOUT, j'ai droit à :
ERREUR : la variable de type RECORD ou ROW ne peut pas faire partie d'une liste INTO à plusieurs éléments

J'ai essayé d'autres syntaxes avec * mais elles produisent une erreur de syntaxe ...

Ya t'il une syntaxe qui convient ?

#23 Re : Migration » [] smallint en paramètre in out d'une fonction » 29/01/2014 12:20:58

CREATE OR REPLACE FUNCTION titi.f_test3(INOUT ma_var2 numeric, INOUT ma_var numeric, INOUT ma_var3 character varying)
  RETURNS record AS
$BODY$
DECLARE
  
BEGIN

ma_var3:='toto';
ma_var:=ma_var+1;
ma_var2:=ma_var2+ma_var;

END ;
$BODY$
  LANGUAGE plpgsql VOLATILE
  COST 100;

(J'ai laissé volatile pour les tests ; une telle fonction devrait être IMMUTABLE si j'ai bien compris la doc, mais j'ai laissé par défaut pour mes tests).

#24 Re : Migration » [] smallint en paramètre in out d'une fonction » 28/01/2014 16:09:00

Oui, c'est ça, je voudrais utiliser certaines fonctions pour des traitements.
C'est certain que je m'éloigne de l'esprit de l'origine des fonctions en SQL.

J'en utilise certaines pour faire des traitements qui auraient aussi bien pu être écrits dans d'autres langages.
Mais ça fonctionnait très bien avec Oracle.

Et j'ai toujours une erreur :

ERREUR: syntaxe en entrée invalide pour le type numeric : « (13,6,toto) »
État SQL :22P02
select into cd_ret1 , cd_ret2, cd_char  titi.f_test3 ( cd_ret1 , cd_ret2, cd_char ) ;

#25 Re : Migration » [] smallint en paramètre in out d'une fonction » 20/01/2014 11:19:42

Mais comment faire si la fonction a en paramètre plusieurs variables INOUT ?
Pgsql dit qu'il faut que le retour soit de type record. Comment alors transférer les données "record" dans les champs initiaux ?
concrètement,
SELECT INTO CD_RET2  F_calcul (Var1, Var2, Var3, Var4, Var5);
comment faire passer dans var1, var2, ... ce qui est dans le record CD_RET2 ?

Pied de page des forums

Propulsé par FluxBB