On 6-1-2018 15:19, m_brahim11@... [firebird-support] wrote:

>
>
> Heres is a sample code of the SP
>
> BEGIN
> FOR SELECT O.ORDRE_ID, O.UNITE_ID, O.NUM_ORDRE, O.PREFIXE, O.DATE_ORDRE,
> O.MOTIF_ORDRE, O.STRUCTURE_ID, O.PROJET_ID, O.BESOIN_NECESSAIRE,
> O.COMMANDE_TRANSMISE, O.UTILISATEUR, O.LAST_UPDATE, O.INTITULE_UNITE,
> O.INTITULE_STRUCTURE, O.NOM_PROJET, O.FILE_EXTENSION
> FROM VW_ORDRE_ACHAT O
>
>  INTO
>   :ORDRE_ID, :UNITE_ID, :NUM_ORDRE, :PREFIXE, :DATE_ORDRE,
> :MOTIF_ORDRE, :STRUCTURE_ID, :PROJET_ID, :BESOIN_NECESSAIRE,
> :COMMANDE_TRANSMISE,
>   :UTILISATEUR, :LAST_UPDATE, :INTITULE_UNITE, :INTITULE_STRUCTURE,
> :NOM_PROJET, :FILE_EXTENSION
>   DO
>   SUSPEND;
> END
>
> The call built in a string variable from the client app is:
>
> SELECT FIRST :NBROW O.* FROM GET_ORDRE_ACHAT O WHERE
> O.ORDRE_ID>=:START_ROW ORDER BY O.ORDRE_ID DESC

That example doesn't do anything that would warrant the use of a stored
procedure.

You would be better off selecting from the table directly, or maybe use
a view, not a selectable stored procedure.

> It works for me but I am worried and planning too if the app wi ll not
> get trouble for the futur in production mode.
> As I have many criteria to choice from client I had left the FOR EXECUTE
> SATEMENT method for this. And according to the advises I received in my
> recents post here to not use FOR EXECUTE SATEMENT.

Please don't take advice for a specific situation as a blanket advice
that applies everywhere. My advice for your previous question was for
that specific code as shown in that question: you were dynamically
constructing a query in a way that was unnecessary for that specific
query as the query wasn't actually dynamic.

Mark

--
Mark Rotteveel