Vous n'êtes pas identifié(e).
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).
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 ...
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
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 ...
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
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 ?
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" ?
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 !
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 ?
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
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 ...
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 ?
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.
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 ...
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';
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
J'ai trouvé mon problème : mon utilisateur était propriétaire du shéma mais pas des tables (c'était postgres).
Maintenant, ça fonctionne ;-)
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.
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 ...
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 ...
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 ...
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 ?
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).
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 ) ;
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 ?