Pb d'ouverture de curseur

Bonjour,

J'ai un pb d'ouverture de curseur dans un prog C :

[valerie(at)nazar valerie]$ ecpg --version
ecpg (PostgreSQL 8.0.0beta1) 3.2.0

extrait du prog :

...
EXEC SQL INCLUDE sqlca;
EXEC SQL BEGIN DECLARE SECTION;
char sqlstmt[ 30720 ]; // string for sql statement
EXEC SQL END DECLARE SECTION;

strcpy( sqlstmt , _strcurs );

EXEC SQL PREPARE s FROM :sqlstmt;
EXEC SQL DECLARE CLICURS CURSOR FOR s;
EXEC SQL OPEN CLICURS;
if ( _verbose )
{
cerr << _(" VS est la :") << endl;
cerr << _("Open clicurs :")<<sqlca.sqlstate<< endl;
cerr << sqlstmt << endl;
}

...

A l'exécution, le PREPARE et le DECLARE se passent bien, et
à l'OPEN j'ai l'erreur sqlcode=-202, soit sqlstate=07001 dont
le libellé est "ECPG_TOO_FEW_ARGUMENTS".

Voici le contenu de la requête :
select u.ID_STATION,u.DAT,u.DAT_CALC,u.DAT_STAMP,u.ORIGINE
,null,null,null ,cast(to_char(dat,'J') as integer) ,u.HRR from H u
where (u.DAT BETWEEN
to_timestamp('10000101000000','YYYYMMDDHH24MISS')::timestamp AND
to_timestamp('30000101000000','YYYYMMDDHH24MISS')::timestamp) AND
(u.id_station between '31069001' AND '31069001' ) order by DAT

et lorsque j'exécute le prog j'obtiens dans un fichier de trace :

VS est la :
Open clicurs :07001
select u.ID_STATION,u.DAT,u.DAT_CALC,u.DAT_STAMP,u.ORIGINE
,null,null,null ,cast(to_char(dat,'J') as integer) ,u.HRR from H u
where (u.DAT BETWEEN
to_timestamp('10000101000000','YYYYMMDDHH24MISS')::timestamp AND
to_timestamp('30000101000000','YYYYMMDDHH24MISS')::timestamp) AND
(u.id_station between '31069001' AND '31069001' ) order by DAT

Si j'exécute cette requête au travers de psql, elle est correcte
et le résultat est celui espéré. Idem en utilisant un curseur.

Je ne comprends pas en premier lieu le code retour de l'erreur : 07001
n'a a priori pas grand chose à voir avec le OPEN (ce serait plutôt
pour un FETCH).

Quelqu'un a-t-il une idée ?

Merci, Valérie.

--

********************************************************************
* Valerie SCHNEIDER Tel : +33 (0)5 61 07 81 91 *
* METEO-FRANCE Fax : +33 (0)5 61 07 81 09 *
* DSI/DEV - Bases de donnees *
* 42, avenue G. Coriolis Email : Valerie(dot)Schneider(at)meteo(dot)fr *
* 31057 TOULOUSE Cedex - FRANCE http://www.meteo.fr *
********************************************************************
* L'information contenu dans ce mail n'a aucun caractere officiel *
********************************************************************

> Bonjour,

Bonjour!

> J'ai un pb [...]
>
> [valerie(at)nazar valerie]$ ecpg --version
> ecpg (PostgreSQL 8.0.0beta1) 3.2.0

Déjà, peux tu essayer avec la béta 3?! Si j'ai bien compté (dans le fichier
"changes since beta1"), il y a une petite dizaine de bugs corrigés, rien que sur
ECPG (momjian et meskes).

> select u.ID_STATION,u.DAT,u.DAT_CALC,u.DAT_STAMP,u.ORIGINE
> ,null,null,null ,cast(to_char(dat,'J') as integer) ,u.HRR from H u
> where (u.DAT BETWEEN
> to_timestamp('10000101000000','YYYYMMDDHH24MISS')::timestamp AND
> to_timestamp('30000101000000','YYYYMMDDHH24MISS')::timestamp) AND
> (u.id_station between '31069001' AND '31069001' ) order by DAT

Cela fait longtemps que je n'ai pas pratiqué ECPG (ni Pro*C d'ailleurs), mais
comme tu n'as pas de réponse, j'en tente une... Sait on jamais!

Ta requête me semble pour le moins curieuse:

a) ton to_timestamp n'est il pas redondant avec le cast ::timestamp?

b) pourquoi dépareiller un peu plus haut en utilisant cast(char) ? :)

c) juste un truc esthétique, renommer la table H en u alors que c'est la
seule table de la requête? :-)

d) perso, j'éviterai les cast via :: dans ecpg.. je ne sais pas trop
pourquoi, mais je ne le sens pas trop :)

A+

PS: oui, presque que du subjectif dans tout ça! :-)

--
Jean-Paul ARGUDO

Site perso : http://www.argudo.org
PostgreSQL : http://www.postgresqlfr.org
l'APRIL : http://www.april.org

Valérie SCHNEIDER writes

> Open clicurs :07001
> select u.ID_STATION,u.DAT,u.DAT_CALC,u.DAT_STAMP,u.ORIGINE
> ,null,null,null ,cast(to_char(dat,'J') as integer) ,u.HRR from H u
> where (u.DAT BETWEEN
> to_timestamp('10000101000000','YYYYMMDDHH24MISS')::timestamp AND
> to_timestamp('30000101000000','YYYYMMDDHH24MISS')::timestamp) AND
> (u.id_station between '31069001' AND '31069001' ) order by DAT
>
> Si j'exécute cette requête au travers de psql, elle est correcte
> et le résultat est celui espéré. Idem en utilisant un curseur.
>
> Je ne comprends pas en premier lieu le code retour de l'erreur : 07001
> n'a a priori pas grand chose à voir avec le OPEN (ce serait plutôt
> pour un FETCH).
>
> Quelqu'un a-t-il une idée ?

Je pense que le SQL PREPARE interprète le ::timestamp comme une variable,
c'est pourquoi par la suite l'erreur indique qu'une variable est attendue.
C'est une erreur dans l'interprétation du SQL et un coup d'oeil au source de
ecpg laisse penser que le patch trivial ci-dessous règlerait le problème:

(le fichier est src/interfaces/ecpg/ecpglib/prepare.c)

*** prepare.c~ Fri May 21 15:50:12 2004
--- prepare.c Wed Sep 29 17:35:58 2004
***************
*** 46,54 ****

if (!string && *ptr == ':')
{
! *ptr = '?';
! for (++ptr; *ptr && isvarchar(*ptr); ptr++)
! *ptr = ' ';
}
}
}
--- 46,59 ----

if (!string && *ptr == ':')
{
! if (ptr[1]==':')
! ptr+=2; // skip '::'
! else
! {
! *ptr = '?';
! for (++ptr; *ptr && isvarchar(*ptr); ptr++)
! *ptr = ' ';
! }
}
}
}

Si vous appliquez ce patch, réinstallez simplement la libecpg après recompil.

--
Daniel
PostgreSQL-powered mail user agent and storage: http://www.manitou-mail.org

Bonjour,

>
> > J'ai un pb [...]
> >
> > [valerie(at)nazar valerie]$ ecpg --version
> > ecpg (PostgreSQL 8.0.0beta1) 3.2.0
>
> Déjà, peux tu essayer avec la béta 3?! Si j'ai bien compté (dans le fichier
> "changes since beta1"), il y a une petite dizaine de bugs corrigés, rien que sur
> ECPG (momjian et meskes).
>
> > select u.ID_STATION,u.DAT,u.DAT_CALC,u.DAT_STAMP,u.ORIGINE
> > ,null,null,null ,cast(to_char(dat,'J') as integer) ,u.HRR from H u
> > where (u.DAT BETWEEN
> > to_timestamp('10000101000000','YYYYMMDDHH24MISS')::timestamp AND
> > to_timestamp('30000101000000','YYYYMMDDHH24MISS')::timestamp) AND
> > (u.id_station between '31069001' AND '31069001' ) order by DAT
>
> Cela fait longtemps que je n'ai pas pratiqué ECPG (ni Pro*C d'ailleurs), mais
> comme tu n'as pas de réponse, j'en tente une... Sait on jamais!
>
> Ta requête me semble pour le moins curieuse:

Oui, mais elle est constituée dynamiquement, il peut y avoir plusieurs
tables (c'est pourquoi il y a renommage), plusieurs conditions (d'où
un between qui pourrait ne pas apparaître), etc.
>
> a) ton to_timestamp n'est il pas redondant avec le cast ::timestamp?

Le to_timestamp me semble nécessaire pour transformer la chaine de
caractère en type timestamp; le "::timestamp" est la solution que
j'avais trouvé pour forcer l'optimiseur à utiliser un index :

clisys=> explain select
u.ID_STATION,u.DAT,u.DAT_CALC,u.DAT_STAMP,u.ORIGINE ,null,null,null
,cast(to_char(dat,'J') as integer) ,u.HRR from H u where (u.DAT
BETWEEN to_timestamp('10000101000000','YYYYMMDDHH24MISS') AND
to_timestamp('30000101000000','YYYYMMDDHH24MISS')) AND (u.id_station
between '31069001' AND '31069001' ) order by DAT;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sort (cost=776067.77..776069.21 rows=2862 width=53)
Sort Key: dat
-> Seq Scan on h u (cost=0.00..776034.91 rows=2862 width=53)
Filter: (((dat)::timestamp with time zone >=
to_timestamp('10000101000000'::text, 'YYYYMMDDHH24MISS'::text)) AND
((dat)::timestamp with time zone <= to_timestamp('30000101000000'::text,
'YYYYMMDDHH24MISS'::text)) AND ((id_station)::text >= '31069001'::text)
AND ((id_station)::text <= '31069001'::text))
(4 lignes)

clisys=> explain select
u.ID_STATION,u.DAT,u.DAT_CALC,u.DAT_STAMP,u.ORIGINE ,null,null,null
,cast(to_char(dat,'J') as integer) ,u.HRR from H u where (u.DAT
BETWEEN to_timestamp('10000101000000','YYYYMMDDHH24MISS')::timestamp AND
to_timestamp('30000101000000','YYYYMMDDHH24MISS')::timestamp) AND
(u.id_station between '31069001' AND '31069001' ) order by DAT;
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sort (cost=5486.68..5488.11 rows=2862 width=53)
Sort Key: dat
-> Index Scan using h_pk on h u (cost=0.00..5453.82 rows=2862
width=53)
Index Cond: (((id_station)::text >= '31069001'::text) AND
((id_station)::text <= '31069001'::text) AND (dat >=
(to_timestamp('10000101000000'::text,
'YYYYMMDDHH24MISS'::text))::timestamp without time zone) AND (dat <=
(to_timestamp('30000101000000'::text,
'YYYYMMDDHH24MISS'::text))::timestamp without time zone))
(4 lignes)

>
> b) pourquoi dépareiller un peu plus haut en utilisant cast(char) ? :)
>
> c) juste un truc esthétique, renommer la table H en u alors que c'est la
> seule table de la requête? :-)
>
> d) perso, j'éviterai les cast via :: dans ecpg.. je ne sais pas trop
> pourquoi, mais je ne le sens pas trop :)

Mais je peux effectivement supprimer les "::" avec "cast ... as ...".

En attendant je tente la beta3.

>
> A+
>
> PS: oui, presque que du subjectif dans tout ça! :-)
--

********************************************************************
* Valerie SCHNEIDER Tel : +33 (0)5 61 07 81 91 *
* METEO-FRANCE Fax : +33 (0)5 61 07 81 09 *
* DSI/DEV - Bases de donnees *
* 42, avenue G. Coriolis Email : Valerie(dot)Schneider(at)meteo(dot)fr *
* 31057 TOULOUSE Cedex - FRANCE http://www.meteo.fr *
********************************************************************
* L'information contenu dans ce mail n'a aucun caractere officiel *
********************************************************************

Le mer 29/09/2004 à 15:52, Daniel Verite a écrit :

Bonjour,
Est-ce que ce patch est inclus dans la beta3 ? J'ai récupéré et compilé
cette dernière version, est-ce qu'elle l'intègre ?
Merci.

> Valérie SCHNEIDER writes
>
> > Open clicurs :07001
> > select u.ID_STATION,u.DAT,u.DAT_CALC,u.DAT_STAMP,u.ORIGINE
> > ,null,null,null ,cast(to_char(dat,'J') as integer) ,u.HRR from H u
> > where (u.DAT BETWEEN
> > to_timestamp('10000101000000','YYYYMMDDHH24MISS')::timestamp AND
> > to_timestamp('30000101000000','YYYYMMDDHH24MISS')::timestamp) AND
> > (u.id_station between '31069001' AND '31069001' ) order by DAT
> >
> > Si j'exécute cette requête au travers de psql, elle est correcte
> > et le résultat est celui espéré. Idem en utilisant un curseur.
> >
> > Je ne comprends pas en premier lieu le code retour de l'erreur : 07001
> > n'a a priori pas grand chose à voir avec le OPEN (ce serait plutôt
> > pour un FETCH).
> >
> > Quelqu'un a-t-il une idée ?
>
> Je pense que le SQL PREPARE interprète le ::timestamp comme une variable,
> c'est pourquoi par la suite l'erreur indique qu'une variable est attendue.
> C'est une erreur dans l'interprétation du SQL et un coup d'oeil au source de
> ecpg laisse penser que le patch trivial ci-dessous règlerait le problème:
>
> (le fichier est src/interfaces/ecpg/ecpglib/prepare.c)
>
> *** prepare.c~ Fri May 21 15:50:12 2004
> --- prepare.c Wed Sep 29 17:35:58 2004
> ***************
> *** 46,54 ****
>
> if (!string && *ptr == ':')
> {
> ! *ptr = '?';
> ! for (++ptr; *ptr && isvarchar(*ptr); ptr++)
> ! *ptr = ' ';
> }
> }
> }
> --- 46,59 ----
>
> if (!string && *ptr == ':')
> {
> ! if (ptr[1]==':')
> ! ptr+=2; // skip '::'
> ! else
> ! {
> ! *ptr = '?';
> ! for (++ptr; *ptr && isvarchar(*ptr); ptr++)
> ! *ptr = ' ';
> ! }
> }
> }
> }
>
> Si vous appliquez ce patch, réinstallez simplement la libecpg après recompil.
--

********************************************************************
* Valerie SCHNEIDER Tel : +33 (0)5 61 07 81 91 *
* METEO-FRANCE Fax : +33 (0)5 61 07 81 09 *
* DSI/DEV - Bases de donnees *
* 42, avenue G. Coriolis Email : Valerie(dot)Schneider(at)meteo(dot)fr *
* 31057 TOULOUSE Cedex - FRANCE http://www.meteo.fr *
********************************************************************
* L'information contenu dans ce mail n'a aucun caractere officiel *
********************************************************************

Valérie SCHNEIDER writes

> Est-ce que ce patch est inclus dans la beta3 ? J'ai récupéré et compilé
> cette dernière version, est-ce qu'elle l'intègre ?

Non il n'est pas inclus, mais si effectivement il résout le problème, je le
suggérerai aux mainteneurs pour la prochaine version...

--
Daniel
PostgreSQL-powered mail user agent and storage: http://www.manitou-mail.org

Le jeu 30/09/2004 à 08:06, Daniel Verite a écrit :
> Valérie SCHNEIDER writes
>
> > Est-ce que ce patch est inclus dans la beta3 ? J'ai récupéré et compilé
> > cette dernière version, est-ce qu'elle l'intègre ?
>
> Non il n'est pas inclus, mais si effectivement il résout le problème, je le
> suggérerai aux mainteneurs pour la prochaine version...

Oui il résout le problème. Maintenant j'ai d'autres problèmes à
l'étape suivante, mais je cherche d'abord... Un FETCH dans des
variables hôtes tableaux. Je pense que c'est possible même si ce
n'est pas explicitement écrit dans la doc.
(Il s'agit d'un portage d'applications Pro*C oracle).
Merci.
--

********************************************************************
* Valerie SCHNEIDER Tel : +33 (0)5 61 07 81 91 *
* METEO-FRANCE Fax : +33 (0)5 61 07 81 09 *
* DSI/DEV - Bases de donnees *
* 42, avenue G. Coriolis Email : Valerie(dot)Schneider(at)meteo(dot)fr *
* 31057 TOULOUSE Cedex - FRANCE http://www.meteo.fr *
********************************************************************
* L'information contenu dans ce mail n'a aucun caractere officiel *
********************************************************************