2017-09-20 2 views
0

J'ai la procédure de Informix suivantefonction Informix retourne sans raison

CREATE FUNCTION selectSollmandant(INOUT sollmandat SOLLMANDAT_ROW, inkassodatum INT8) RETURNING SMALLINT 
DEFINE ret SMALLINT; 
LET ret = 0; 
trace "Entering select sollmandat " || sollmandat.vers_schein_nr; 

PREPARE sollStmt FROM "SELECT s::SOLLMANDAT_ROW FROM sollmandat s WHERE vers_schein_nr = ? ORDER BY lfdnr desc"; 

DECLARE _sollmCsr CURSOR FOR sollStmt; 
IF SQLCODE != 0 THEN 
    CALL print_to_proto("DECLARE letztZahlCsr " || SQLCODE); 
    RETURN 0; 
END IF; 

TRACE "log =========== 1"; 
OPEN _sollmCsr USING sollmandat.vers_schein_nr; 
TRACE "log =========== 2" || SQLCODE; 

IF SQLCODE != 0 THEN 
    TRACE "log =========== 3" || SQLCODE; 
    CALL print_to_proto("OPEN sollmandat " || SQLCODE); 
    RETURN 0; 
END IF; 
TRACE "sollmandant iban is =========== 4" || SQLCODE; 
WHILE (1=1) LOOP .... end loop and return... 

problème est que mon retour de la fonction avant d'atteindre la boucle while et il frappe jamais log2, log 3 ou log 4.

Can vous s'il vous plaît aidez-moi? Je ne vois pas ce qui me manque.

Merci pour l'aide.

+0

Quelle version d'Informix est exécutée sur quelle plateforme? Devons-nous supposer que le code atteint "log 1" mais pas les messages de journal plus tard? La notation 'SELECT s :: SOLLMANDAT_ROW FROM ... 'est déroutante. Que pensez-vous qu'il fait? Voulez-vous dire 's.SOLLMANDAT_ROW'? Vous n'avez pas d'erreur de trapping (SUR EXCEPTION), donc si l'OPEN échoue à cause de cela, vous ne verrez pas le message 'log 2', –

+0

Oh, euh - vous avez besoin de fournir un MCVE ([MCVE]) . Il semble que SOLLMANDAT_ROW soit un UDT dans la base de données. Mais vous ne nous avez pas montré ce que c'est. Vous n'avez pas montré la structure de la table 'sollmandat'. Vous ne nous avez pas fourni ce qui est nécessaire pour que cela fonctionne sur nos systèmes. Avez-vous exécuté le SQL seul - l'instruction SELECT devrait être exécutable dans DB-Access, je pense. Votre code m'a confondu à 100% (ce qui prend un peu de temps). S'il vous plaît nous fournir le MCVE. Est-ce que vous prévoyez de parcourir une variable? –

Répondre

0

J'ai réussi à résoudre le problème, mais avant d'entrer dans la façon dont je l'ai fait, je veux essayer de clarifier ce que le code affiché ci-dessus signifie réellement.

CLARIFICATION

Ok, donc le SOLLMANDAT_ROW est un ROW_TYPE que I définie (penser un objet struct comme données pour les procédures stockées). La fonction mentionnée ci-dessus fait partie d'une grande UDR et nous utilisons une ligne de données pour faciliter la manipulation des données. La fonction doit sélectionner une ligne de ma table sollmadant et stocker la ligne dans mon SOLLMANDAT_ROW personnalisé.

Afin de pouvoir stocker les lignes sélectionnées dans ROW_TYPES, la ligne doit être explicitement convertie vers ce type de ligne spécifique, d'où la syntaxe SELECT s::SOLLMANDAT_ROW FROM....

SOLUTION REELLE

Il est avéré que le problème était curseur se rapportent, vous voyez, dans le contexte dans lequel je courais la fonction, la table interrogée était synonyme , et mon code rompait à la OPEN cursor déclaration. Ce que je l'ai fait afin d'obtenir passer la question est de se référer à mes données de ligne comme ceci:

SELECT ROW([row colums gere ])::SOLLMANDAT_ROW [rest of select statement] 

Après avoir fait ce changement, la fonction se comporte comme il se doit.

Je ne sais pas vraiment pourquoi informix ne "aime" pas la syntaxe de ma première sélection lorsque je tente de stocker des lignes à partir de tables de synonymes dans des types de lignes personnalisées spécifiques. Et si quelqu'un peut fournir une explication, je serais très reconnaissant.

J'espère que ce message sera utile aux autres, et je vous remercie pour votre temps.

+0

Créé quelques procédures similaires (très simples) dans Informix version 12.10.FC9DE et je n'ai eu aucun problème avec les distributions 'ROW'. Pourriez-vous fournir votre version d'Informix? Et quelles erreurs SQL + ISAM sont renvoyées? Ou fournir un MCVE comme Jonathan a demandé. –

+0

Bonjour, il n'y a pas eu d'erreur SQL + ISAM retournée et la version informix est 11.70. – user2960896

+0

Une exception devrait être levée lorsque le curseur est 'OPEN'. Mais il est probablement pris quelque part dans ce grand UDR que vous mentionnez. Essayez ce que Jonathan a écrit dans le 1er commentaire, placez un 'ON EXCEPTION' dans cette procédure particulière, en utilisant la clause' SET' pour capturer l'erreur et écrivez-le avec 'TRACE'. –