Passage du paramètre nom de la table ds une Procédure Stocké [Résolu]

[moucrack]

Bonjour à tous et merci,
J'ai une base de donnée crée sous Firebird 1.5.
Je veux passer le nom d'une table comme paramètre dans une procédure stocké.
Tous d'accord, qu'avec Intrebase c impossible, mais avec firebird c possible.
Bon, j'ai l'essayé avec firebird mais même pb !!!!
et voici mon code de la procédure stocké :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
ALTER PROCEDURE PS_UPDATE_SEQ 
AS
DECLARE VARIABLE ENTITE VARCHAR(30);
DECLARE VARIABLE I INTEGER;
begin
    FOR
    SELECT entite FROM sequenceur INTO :entite
    do
        begin
          execute statement 'select max(id) from ' || :entite INTO :i; 
          suspend; 
         UPDATE sequenceur seq SET seq.compteur = :i  WHERE seq.entite = :entite;
        suspend;
        end
 end

Pour comprendre ce code :
on a table sequenceur contenant la liste des nom des tables dans la colonne entite et leurs compteurs d'id.
sequenceur (entite varcher(30), compteur integer)
Pour chaque nom du table faire : calculer le max des id et l'affecter au variable i.
puis mettre à jour le compteur de la table sequenceur pour chaque entite (nom table) parcouru.

Je crois que c clair. (espérent bien bien sûr)

lors de l'execution tous va bien mais qds je vérifi la colonne compteur de la table sequenceur rien n'a été changé !!! (bien sûr j'ai fait tout les commit)

[/code]

[Barbibulle]

Etant donné que c'est une procédure qui ne retourne aucunnes données, il ne faut surtout pas mettre de suspend.

Enlevez les suspends et je pense que tout irra mieux.

Je suppose que les ID des tables sont gérés par des générateurs (sinon vous allez avoir des problemes si votre application est sencée être multi-users).

Donc si vous avez des générateurs pourquoi ne pas lire les valeurs des générateurs plutot que de faire un max(id) sur chaque table qui a mon avis est plus couteux.

[moucrack]

Enlevez les suspends et je pense que tout irra mieux.

j'ai essayé sans suspend et tout va bien. merci.

mais, j'ai des questions qui manquent des justifications :
- est ce que execute statement peut fonctionner sous interbase? Rep oui, mais comment Firebird == interbase même famille ?
- si ma procédure ne retourne aucunnes données, est ce que le suspend gène l'execution de cette procédure? reponse oui, mais sans justification ?

Je suppose que les ID des tables sont gérés par des générateurs (sinon vous allez avoir des problemes si votre application est sencée être multi-users).

Non, mes id ne sont pas gérés par des générateurs, mais ils sont gérés par une autre procedure stocké GetNextId que j'ai le crée et qui remplace le Gen_Id. car je veux que ma base assure au moins un taux de portabilité plus élévé, vue que les générateurs sont spécifiques à interbase et firebird.

y a t-il des commentaires ?

[Barbibulle]

Envoyé par moucrack

j'ai essayé sans suspend et tout va bien. merci.

mais, j'ai des questions qui manquent des justifications :

Voilà bien des exigeances

Envoyé par moucrack

- est ce que execute statement peut fonctionner sous interbase?

NON : Borland a donné au monde du logiciel libre Interbase V6, mais tout compte fait il décide de ne plus l'abandonner et de continuer Interbase (mais comme la V6 était déjà dans le domaine du libre ils ne pouvaient plus le retirer, ce qui est donné est donné... (enfin je dit ca mais je ne pense pas qu'ils aient essayé de l'enlever du libre)) Donc Interbase 6 est figée, plus de correction de bug ni d'amélioration. Pour avoir un produit vivant il faut soit acheter Interbase 7.5 soit passer à Firebird. La version 1 de Firebird est basée sur les sources en C d'interbase 6, pratiquement aucunnes amélioration n'a été apporté, juste la correction des bugs connus d'IB6 et le portage sur plus d'OS. Firebird1.5 quand à lui a été réécrit en C++ et de nombreuses améliorations sont présentes.
Execute Statement fait parti de ces nouveautées et donc cette fonction n'existe pas sous IB6. (Je ne suis même pas certain qu'elle soit dispo sous IB7.5).

Envoyé par moucrack

- si ma procédure ne retourne aucunnes données, est ce que le suspend gène l'execution de cette procédure? reponse oui, mais sans justification ?

A votre avis que fait le suspend ? il alimente le buffer de sorti et attend que le client fasse un fetch pour réclamer le suivant ou que se soit le dernier élément à envoyer (dans ce cas il sort tout seul). Dans votre cas, il se met en attente, vu que ce n'est pas le dernier enregistrement et aucun fetch n'est demandé par le client vu que celui ci sait très bien qu'il n'y a pas de résultat à lire (pas de paramétres de retours). Bref il ne se passe rien.

Envoyé par moucrack

Non, mes id ne sont pas gérés par des générateurs, mais ils sont gérés par une autre procedure stocké GetNextId que j'ai le crée et qui remplace le Gen_Id. car je veux que ma base assure au moins un taux de portabilité plus élévé, vue que les générateurs sont spécifiques à interbase et firebird.

y a t-il des commentaires ?

L'utilisation des générateurs est plus performant. Je ne sais pas quel technique vous avez utilisé dans votre procédure mais si ce n'est pas celle d'une table des clés externe, elle ne sera pas fiable (à moins comme je vous l'ai déjà dit que votre base soit destinée à une en utilisation Monoposte. ). Sans compter que si vous avez fait une procédure celle ci ne sera pas portable. Donc vous n'utilisez pas les générateurs pour une mauvaise raison (Vous n'utilisez pas les générateurs parce que ce n'est pas portable et en solution de remplacement vous utilisez une méthode non portable et moins performante).
De plus même si dans votre procédure vous utilisez la méthode de la table des clés externe qui est la seule a être à peu pres portable (à condition de ne pas utiliser les procédures) il faut faire extrement attention à la façon de procéder et surtout du type de transaction utilisé pour mettre à jour cette table des clés sinon encore une fois le risque est de se retrouver avec des doublons.