Le forum (ô combien francophone) des utilisateurs de Powerbuilder.
Bonjour à tous,
J'ai un petit problème en ce qui concerne la récupération d'une chaine de caractère à travers une procédure stockée.
Cette procédure stockée est définie comme ceci ...
Create Proc OBI_S_REV_PRECEDENT_v3 (
@ID_REV int,
@QTE_DEMANDEE int output,
@QTE_LIVREE int output,
@PRESTATAIRE varchar(30) output,
@D_LIVRAISON datetime output
)
... et est implémentée dans PB comme ceci
function long OBI_S_REV_PRECEDENT_v3(long ID_REV,ref long QTE_DEMANDEE,ref long QTE_LIVREE,ref string PRESTATAIRE,ref datetime D_LIVRAISON) RPCFUNC ALIAS FOR "dbo.OBI_S_REV_PRECEDENT_v3"
Le problème est que quand j'utilise ma procédure stockée dans mon code PB, seul la variable représentant une chaîne de caractères n'est pas renvoyée (chaîne vide) alors que si j'exécute la procédure à la main j'ai bien une valeur pour mon prestataire
ll_code_retour = SQLCA.OBI_S_REV_PRECEDENT_v3( & l_l_id_rev, & ref ll_qte_dem_prec, & ref ll_qte_liv_prec, & ref ls_prestataire_prec, & ref ldt_date_liv_prec)
Est ce que vous voyez d'où ça pourrait provenir?
J'ai essayé de déclarer en char ou varchar du coté de la procédure stockée mais rien n'y change.
Dernière modification par Nephtis (14-12-2009 10:11:07)
Hors ligne
Nephtis a écrit:
Code: pb
ll_code_retour = SQLCA.OBI_S_REV_PRECEDENT_v3( & l_l_id_rev, & ref ll_qte_dem_prec, & ref ll_qte_liv_prec, & ref ls_prestataire_prec, & ref ldt_date_liv_prec)Est ce que vous voyez d'où ça pourrait provenir?
J'ai essayé de déclarer en char ou varchar du coté de la procédure stockée mais rien n'y change.
Bonjour, pourquoi utiliser des ref dans l'appel ?
Hors ligne
Les "ref" sont inutiles en effet pour l'appel.
Et pense bien à initialiser ls_prestataire_prec avec space(30) ou équivalent avant d'appeler la fonction, sinon gare aux débordements mémoire qui font planter l'application.
Hors ligne
Salut
faut chercher dans l'aide 'procedure fetch'
exemple
To access rows returned in a result set, you use the FETCH statement the same way you use it for cursors. The FETCH statement can be executed after any EXECUTE statement that refers to a procedure that returns a result set.
Example 1
FETCH emp_proc INTO :emp_name_var;
You can use this FETCH statement only to access values produced with a SELECT statement in a database stored procedure. You cannot use the FETCH statement to access computed rows.
Database stored procedures can return multiple result sets. Assume you define a database stored procedure proc2 as follows:
CREATE PROCEDURE proc2 AS
SELECT emp_name FROM employee
SELECT part_name FROM parts
PowerBuilder provides access to both result sets:
// Declare the procedure.
DECLARE emp_proc2 PROCEDURE FOR proc2;
// Declare some variables to hold results.
string emp_name_var
string part_name_var
// Execute the stored procedure.
EXECUTE emp_proc2;
// Fetch the first row from the first result
// set.
FETCH emp_proc2 INTO :emp_name_var;
// Loop through all rows in the first result
// set.
DO WHILE sqlca.sqlcode = 0
// Fetch the next row from the first result set.
FETCH emp_proc2 INTO :emp_name_var;
LOOP
// At this point we have exhausted the first
// result set. After this occurs,
// PowerBuilder notes that there is another
// result set and internally shifts result sets.
// The next FETCH executed will retrieve the
// first row from the second result set.
// Fetch the first row from the second result
// set.
FETCH emp_proc2 INTO :part_name_var;
// Loop through all rows in the second result
// set.
DO WHILE sqlca.sqlcode = 0
// Fetch the next row from the second result
// set.
FETCH emp_proc2 INTO :part_name_var;
LOOP
The result sets that will be returned when a database stored procedure executes cannot be determined at compile time. Therefore, you must code FETCH statements that exactly match the format of a result set returned by the stored procedure when it executes.
Example 1 These statements associate a cursor named my_cursor with SQLSA, prepare a SELECT statement in SQLSA, open the cursor, and return the employee ID in the current row into the PowerScript variable Emp_id_var:
integer Emp_id_var
DECLARE my_cursor DYNAMIC CURSOR FOR SQLSA ;
PREPARE SQLSA FROM "SELECT emp_id FROM employee" ;
OPEN DYNAMIC my_cursor ;
FETCH my_cursor INTO :Emp_id_var ;
CLOSE my_cursor ;
You can loop through the cursor as you can in embedded static SQL.
Example 2 These statements associate a cursor named my_cursor with SQLSA, prepare a SELECT statement with one parameter in SQLSA, open the cursor, and substitute the value of the variable Emp_state_var for the parameter in the SELECT statement. The employee ID in the active row is returned into the PowerBuilder variable Emp_id_var:
DECLARE my_cursor DYNAMIC CURSOR FOR SQLSA ;
integer Emp_id_var
string Emp_state_var = "MA"
string sqlstatement
sqlstatement = "SELECT emp_id FROM employee "&
+"WHERE state = ?"
PREPARE SQLSA FROM :sqlstatement ;
OPEN DYNAMIC my_cursor using :Emp_state_var ;
FETCH my_cursor INTO :Emp_id_var ;
CLOSE my_cursor ;
Hors ligne
En effet les ref sont bien inutiles lors de l'appel de la fonction (je pensais que ça permettait à PB de s'y retrouver parmi les paramètres en input et en output)
Le fait d'initialiser la variable ls_prestataire_prec avec space(30) permet de récupérer le résultat stocké en base (ça j'ai pas encore vraiment compris pourquoi le fait d'initialiser la variable permet de pouvoir récupérer le résultat renvoyé par la procédure stockée)
C'est sous quelle version de PB que tu as retrouvé cette doc JCZ? Sous la doc de PB6.5 ils sont un peu plus avares dans leurs exemple
Vous voulez votre lots de Kpépites ou vous en avez tellement que 1 milliard de plus ou de moins ça ne se verrais pas
Hors ligne
Nephtis a écrit:
Le fait d'initialiser la variable ls_prestataire_prec avec space(30) permet de récupérer le résultat stocké en base (ça j'ai pas encore vraiment compris pourquoi le fait d'initialiser la variable permet de pouvoir récupérer le résultat renvoyé par la procédure stockée)
En fait, l'initialisation space(20) force PB à faire à coup sûr une allocation mémoire en sous-main. Les programmes externes appelés (API Windows, DLL diverses, client SQL) ne font pas cette allocation qui incombe à l'appelant. Si elle n'est pas faite, le contenu du buffer en sortie ira écraser les variables voisines, voire l'adresse de retour d'un appel de sous-programme. Sanction immédiate (ou pas, ce qui est pire), plantage du programme ou au moins comportement bizarre.
Comme quoi, PB a beau être un L4G, il faut parfois se préoccuper d'allocation mémoire, pointeurs et autres joyeusetés des langages de plus bas niveau !
Nephtis a écrit:
Vous voulez votre lots de Kpépites ou vous en avez tellement que 1 milliard de plus ou de moins ça ne se verrais pas
Ça dépend... la devise PDP (Pépites PbaDonf) est-elle exotique ou le taux de conversion EUR/PDP est-il intéressant ?
Hors ligne