On 6-1-2018 15:19, [email protected] [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
