Erreur dans une procédure [Résolu]

[dug]

Bonjour,

j'ai une erreur que je ne comprends pas, sous Firebird 2.5

je ne mets pas tout le code de la procédure, mais l'erreur ce trouve ici:

Code :

1
2
3
4
5
6
7
8
9
10
 
...
 
	EXECUTE STATEMENT 'INSERT INTO T ( I, TXT, DAT ) VALUES ( 1, '''||:sTable||': avant IF (rownum_last:'||:rownum_last||' < cpt_all:'||:cpt_all||')'', current_timestamp )';
 
	--	vérifie si des lignes sont à traiter
	IF (rownum_last < cpt_all) THEN BEGIN
		EXECUTE STATEMENT 'INSERT INTO T ( I, TXT, DAT ) VALUES ( 1, '''||:sTable||': apres IF (rownum_last:'||:rownum_last||' < cpt_all:'||:cpt_all||')'', current_timestamp )';
 
...

je logue bien avant le IF:
"NOTE: avant IF (rownum_last:179 < cpt_all:180)"

mais la comparaison des 2 valeurs (qui sont bien de type INTEGER toutes les deux) me génère une exception avec le sqlcode -802

je ne vois pas ce qu'y pose problème pour la comparaison...
quelqu'un a une piste ?

[makowski]

pourquoi des execute statement ici ?

[dug]

je n'ai peut être pas bien compris l'execute statement.

j'utilise execute statement principalement pour avoir l'insert directement dans la base, sans attendre la fin de la transaction...

bref, pour mon problème, cela ne vient pas de la je pense.
pour info, je viens de migrer de 2.1 en 2.5, je suis partie à partir d'une base vide creer avec flamerobin, puis en utilisant mes scripts de création de base.
J'ai changé le charset en ISO8859_1 à la création de la base.

en utilisant flamerobin et la requête:

Code :

1
2
 
SELECT CODE_ERROR FROM UPDATE_HASH_TABLE('NOTE', 'NOTE')

cela fonctionne correctement.

en passant par mon code C++ avec la librairie ibpp, je me retrouve avec l'exception 802, alors que la procédure se lance bien puisqu'il fait quelques traitements avant d'avoir l'erreur...

avec ibpp, j'ai essayé 2 façon de l'écrire (dont je n'ai pas bien compris la différence non plus). Les 2 solutions lancent bien la procédure, mais finisse toutes les deux en exception...

Code :

1
2
3
4
5
6
7
8
9
10
11
12
 
sQuery = SELECT CODE_ERROR FROM UPDATE_HASH_TABLE(...)
stl->Prepare( wx2std(sQuery.GetData()) );
stl->CursorExecute( wx2std(sCursorName) );
 
IF( stl == NULL ) {
	RETURN( false );
}
stl->Fetch();	//	parcours la première ligne pour executer la procédure
 
int		i;
bool	bNull = stl->Get("CODE_ERROR", &i);

Code :

1
2
3
4
5
6
7
8
9
10
11
 
sQuery = EXECUTE PROCEDURE UPDATE_HASH_TABLE ...)
 
stl->Prepare( wx2std(sQuery.GetData()) );
stl->Execute( wx2std(sQuery.GetData()) );
IF( stl == NULL ) {
	RETURN( false );
}
 
int		i;
bool	bNull = stl->Get("CODE_ERROR", &i);

je ne comprends pas d'ou vient le problème

[makowski]

je n'ai peut être pas bien compris l'execute statement.

manifestement oui

j'utilise execute statement principalement pour avoir l'insert directement dans la base, sans attendre la fin de la transaction...

http://www.firebirdsql.org/file/docu...-execstat.html

bref commencez par supprimer votre execute statement qui ne sert à rien
le code sera plus simple, plus lisible

ensuite éventuellement utilisez WITH AUTONOMOUS TRANSACTION

mais le fait que cela passe avec FR et pas avec votre code laisse penser à un mauvais encodage des données
il faut vérifier votre chaine de connexion

avec ibpp, j'ai essayé 2 façon de l'écrire (dont je n'ai pas bien compris la différence non plus)

avec select vous attendez un ensemble de données en résultat (et donc vous devez avoir un SUSPEND dans votre procedure, sans select, vous executer la procedure qui ne retourne pas d'ensemble de données

[dug]

merci Philippe de tes réponses.

pour les execute statement, je m'en sers pour ce genre de requête:

Code :

1
2
 
EXECUTE STATEMENT 'SELECT count(*) FROM ALL_'||:sTable||' WHERE '||:sPrefix||'_DATE > '''||:date_last||'''' INTO cpt_all;

le fonctionnement standard est le même que le insert de base, et je suis bien obligé de passer par execute statement pour ce genre de requête non ?

sympa en tout cas les nouvelles options de execute statement, et la posibilité de faire des requêtes multi-base c'est bien cool

sinon, pour mes petits problèmes, voici mes conclusions (qui peuvent être incorrecte...) :

1/ pas simple de déboguer en PSQL, car il traite des lignes à l'avance et génère plutôt l'exception...
ex: mon problème décrit dans le 1er post, on a l'impression que c'est la comparaison du IF qui plante, alors que l'erreur était plus bas dans le code !!

2/ j'ai dis n'importe quoi... quand on sait pas écrire du code correctement...
il précompile l'intérieur des chaînes dans certain cas !!
ex:
EXECUTE STATEMENT 'INSERT INTO T ( I, TXT, DAT ) VALUES ( 1, ''__ rdb$get_context(USER_TRANSACTION, hash#)'', current_timestamp )';
EXECUTE STATEMENT 'INSERT INTO T ( I, TXT, DAT ) VALUES ( 1, ''__ rdb$get_context(''USER_TRANSACTION'', ''hash#'')'', current_timestamp )';

la première ligne ne plante pas, la deuxième plante avec l'exception 104 !!

3/ j'ai l'impression qu'il y a une différence de traitement entre la v2.1 et la v2.5 dans la mémorisation d'une vue (à retester en v2.1 pour confirmation)

dans mon script de création, la création de la vue est sous cette forme, avec le retour à la ligne après AS:

Code :

1
2
3
CREATE VIEW vv ( ... )
AS
SELECT ...

la requete suivante retourne la source de la vue, et du coup retourne en 1er caractère le retour à la ligne, à tester en v2.1

Code :

SELECT SUBSTRING( RDB$VIEW_SOURCE FROM 1 FOR 32000 ) FROM RDB$RELATIONS WHERE RDB$VIEW_SOURCE IS NOT NULL

mais bon, problème résolu c'est l'essentiel...