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 ?

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 ;

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 ?