Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Merci pour cette réponse ! J'avais pensé à une solution de la sorte mais je ne trouvais pas comment faire.
Par contre, un problème se pose. Mon application est multi utilisateurs et fonctionne en multithreading. Il est donc possible que le code.erreur soit modifié par un second utilisateur avant d'être récupéré par le premier utilisateur.
Entre temps j'ai réfléchi à une autre solution. Créer une table stockant les erreurs, et dans mon client, exécuter la procédure, et interroger la table pour récupérer l'erreur correspondant. Mais ici même problème, le cas du multi utilisateurs...
Une idée ?
Merci !
Je vois quand vous renvoyez 101, mais pas quand vous renvoyez 102.
Si vous ne renvoyez qu'un code d'erreur, le fait de récupérer ou non une ligne permet d'émuler ce code d'erreur.
Le code client contient tous les messages de toutes les erreurs possibles de mes 650 procédures. Le -102 n'est simplement pas traité dans cette procédure.
Ce que je voulais dire c'est qu'un return(1) sous Sybase est normalement synonyme d'erreur.
Il semble que dans ce cas il devrait plutôt y avoir un return(0).
Le return(1) me sert uniquement de test de bon exécution de ma procédure dans le cas où elle est appelée dans une autre procédure stockée. Savoir si je peux poursuivre les traitements ou non.
bonjour,
À toutes fins utiles:
http://virginie.quesnay.free.fr/index.p … postgresqlCela avait été repris sur PGFr il y a quelques temps:
http://blog.postgresql.fr/index.php?post/drupal/29Cordialement,
Bonjour,
Merci pour ce site, mais apparemment les procédures stockées ne sont pas migrées 
Si je comprends bien, la procédure COU_ExistId fait un select sur la base pour voir si l'identifiant existe.
La procédure COU_Get appelle COU_ExistId (pour savois si l'id existe), puis, si l'id existe, sélectionne le 'cou'.Pourquoi faire 2 fois la même chose?
Tu peux déjà commencer par simplifier en supprimant la procédure COU_ExistID et en faisant directement le 2ème select. Ca sera plus simple, plus performant (sans compter que si une transaction concurrente supprime la ligne entre les 2 requêtes, tu risques des surprises)
Sinon, pour en revenir au problème principal, il est beaucoup plus logique que ce soit le client qui vérifie s'il y a des lignes renvoyées (l'absence de résultat n'est pas un problème technique, mais fonctionnel).
Apparemment tu es en train d'adapter le client de toute façon? Pourquoi est-ce un problème de modifier légèrement le client? (avec ton exemple je ne comprend pas très bien). Si tu dois vraiment afficher ou loguer le même code d'erreur que dans l'application d'origine, au pire tu peux ajouter une couche au client, qui traite la requête et crée le code et le message d'erreur en fonction de la procédure appelée...
J'ai volontairement écourté la procédure qui faisait 50 lignes, c'était juste pour donner un exemple de cas problématique avec un select et un return.
Le client vérifie si des lignes sont renvoyées à l'aide des alias PGRES_COMMAND_OK etc.., et procède au traitement des données ensuite. Ce que j'appelle "le client", c'est l'application d'origine 
Rectification:
En lisant la documentation, il semble qu'une fonction renvoyant un SETOF ne peut se terminer qu'avec un RETURN sans argument
C'est malheureusement le problème
Quel intérêt de renvoyer un code retour vu qu'on a le résultat de la requête ? si on y tient vraiment, le seul moyen est de renvoyer le code sur chaque ligne renvoyée. En dehors de ça, point de salut.
L'intérêt est de s'en servir pour un IF en appelant cette procédure dans une autre, suivant le code retour (cas 1 de la procédure ci-dessous). C'est aussi pour une exploitation du code retour par l'application cliente qui affiche un message particulier à l'utilisateur suivant le code retourné (cas 2).
exemple Sybase que je voudrais reproduire:
-----------------------------------------------------
CREATE PROCEDURE COU_Get
@id int
as
begin
declare @result smallint
begin transaction
/* Si la procédure COU_ExistId retourne 1, l'id existe, sinon elle retourne 0 */
exec @result = COU_ExistId @id /* CAS 1 */
/* En cas d'absence */
if (@result=0)
begin
rollback transaction
raiserror 21001 "", "Coup"
return (-101) /* CAS 2 */
end
/* Récupération des informations associées au coup */
select
CAM_ID,
BAL_ID,
COU_REF,
COU_COND_CHARGE,
COU_COND_TEMPERATURE,
COU_COND_HAUSSE,
COU_COND_GISEMENT,
from COU
where COU_ID=@id
commit transaction
return(1)
end
-----------------------------------------------------
Le code client est du style :
switch(status) /* 'status' correspondant au code retour récupéré par un 'exec' de la procédure */
case -101 : printf('Erreur sur la table COU, ID inexistant');
break;
case -102 : printf('Erreur sur la table COU, REF inexistante');
break;
....
Merci
Bonjour,
Je procède actuellement au remplacement d'un serveur Sybase par un serveur PostgreSQL, et j'ai un gros problème de migration de mes procédures stockées.
Ma question est simple, comment faire pour qu'une procédure stockée postgresql exécute un "select" (dont le résultat peut être récupéré par un objet PGresult avec la commande PQexec dans mon code client), et retourne aussi un entier qui me sert de code erreur pour le traitement côté client ?
exemple de procédure Sybase qui me pose problème avec postgresql:
create procedure maproc
as
begin
select * from matable;
return(1);
end
Merci d'avance
Bonne journée
Pages : 1
