Too many Contexts of Relation/Procedure/Views [Résolu]

[freud]

Bonjour à tous et à toutes,

Voilà que subitement j'obtiens le message ci-dessous lorsque je recompile une SP :

Code :

1
2
3
4
 
Undefined name.
Too many Contexts of Relation/Procedure/Views. Maximum allowed IS 255.
Error while parsing procedure SP_TRANSFORM_PIECE's BLR.

J'ai vu quelque part que FB ne pouvait faire que 255 changements des tables et vues et qu'il fallait faire un backup/restore pour remettre à zéro le compteur des révisions mais ça n'a pas fonctionner
J'ai même tenter un gfix -sweep....toujours pas.

Si quelqu'un à une idée ?

Merci.

[TryExceptEnd]

Ta PS doit être particulièrement complexe (un plat de spaghetti quoi !) pour lever cette erreur rare, en fait c'est le nombre de tables, PS selectionnables, vues... utilisés dans cette PS qui dépasse les 255.
La solution est de simplifier ta PS au max.

[freud]

Envoyé par TryExceptEnd

Ta PS doit être particulièrement complexe (un plat de spaghetti quoi !)

Exactement c'est un plat de spaghetti, c'est bien dit.
c'est la PS la plus complexe dans le projet et la plus fondamentale disons que c'est le pillier dans la BDD. Pour la construire, j'avais à porter de la main de la paracétamol

En effet, j'ai dû réduire le nombre de tables et de vues , juste pour voir, et ça a merveilleusement fonctionner. Maintenant je vais réserver une bonne journée pour réviser et optimiser cette PS

Merci TryExceptEnd

[TryExceptEnd]

Si ta PS est un plat de spaghetti, la modélisation de ta base doit être du même tonneau. Car il y a aucune raison pour qu'une PS (SP_TRANSFORM_PIECE) qui transforme une pièce commerciale en une autre soit aussi compliquée que ça.

[freud]

Bonjour,

Envoyé par TryExceptEnd

la modélisation de ta base doit être du même tonneau.

Non, je ne pense pas, la BDD est bien modélisée avec des tables maitres et des tables de détails. Il s'agit de transformer dix types de pièces commerciales (achat et vente)
Vente : devis=>commande=>livraison=>facture=>avoir
achat : devis=>commande=>livraison=>facture=>avoir (je n'ai pas encore introduis l'ordre d'achat....) et d'autres pièces de stocks.

Une table type de pièces contient toutes les pièces disponibles avec leurs identifiants gérer par le programme.

Une autre table (Pièce) dans laquelle sont stockés les pièces générer avec les informations de quelle pièce la pièce courante a été générer et quelle pièce sera générer depuis la pièce courante. Ca permet d'enchainer les pièces les unes d'avec les autres. La transformation consiste de copier par exemple, les tables devis et devis_ligne dans commande et commande_ligne.

Il n' y a pas d'écrans avec les grilles devis, commande, facture etc... distinctement. C'est est un plat de spaghetti qui 'est afficher à leur places c'est à dire toutes les pièces dans une seule grille. Sans compter le module des stocks (PUMP,LOT,FIFO,SERIALISER) ainsi que la gestion des emplacements, du type d'emplacement et leurs entités.

Le projet est un tonneau pour cela je pense que oui. Enfin tel que je le vois.

la PS en question a été construite rapidement, disons sans réflexion du fait qu'il reste beaucoup de chose à réalisé, peut-être bien qu'en la revoyant elle sera simplifié.
Voilà TryExceptEnd

[Barbibulle]

Bonjour,

Je ne connaissais pas cette limitation, du coup je me suis "amusé" à regarder combien j'avais de dépendance directe par procédure sur mon plus gros projet.
Je suppose que la contrainte ne tiens compte que les dépendances directes ? C'est a dire une PS1 qui appel une autre PS2 compte pour 1 dépendance (même si PS2 appel 10 tables).
Je ne suis pas certain à 100% que la requête suivante soit juste, (je ne l'ai vérifiée que pour une PS).

Code :

1
2
3
4
5
6
WITH CTE (NOM_PS, NbrDependance) AS (
SELECT D.RDB$DEPENDENT_NAME, count(DISTINCT D.RDB$DEPENDED_ON_NAME) nbrDependance
FROM RDB$DEPENDENCIES D
WHERE d.rdb$dependent_type=5
GROUP BY D.RDB$DEPENDENT_NAME )
SELECT count(c.NOM_PS) AS "Nombre PS", AVG(NbrDependance) AS "Moy dependance par PS", Max(NbrDependance) AS "Nbr max dependance pour une PS" FROM cte c

Elle me renvoie que j'ai 300 PS, avec en moyenne 5 dépendances par PS et le maximum de dépendance d'une de mes PS est de 43 (donc je suis encore loin des 255).

[freud]

Envoyé par Barbibulle

Je suppose que la contrainte ne tiens compte que les dépendances directes ? C'est a dire une PS1 qui appel une autre PS2 compte pour 1 dépendance (même si PS2 appel 10 tables).

Je suppose que oui, pas seulement des dépendances directes.
Parce quez j'ai supprimer une vue qui a des dépendances et l'ai remplacer par l'appel d'une PS qui n'en a pas, le problème persistait.

Par contre, j'ai dû enlever l'appel d'une vue ou d'une table dans la PS et le problème a disparu.

Donc les 10 tables de PS2 sont compter dans la limitation.

[freud]

Barbibulle :
Le code me renvoi le résultat suivant :
Nombre PS : 139
Moy dependance par PS : 3
Nbr max dependance pour une PS : 24
Moi aussi je suis encore loin des 255
Les UNION, les AGRREGATIONS, les DISTINCT je pense qu'ils sont aussi pris dans le compte

Pour info : la limite est de 127 dans les versions antérieures à la version 2

[Barbibulle]

En effet, cela me fait peur....

J'aimerai bien trouver la requête qui permettrait de calculer ce nombre.

[freud]

Voici dans ce lien, ce que dis Yemanov, un des developpeur de FB, dans un topic, en réponse au même problème :
http://tech.dir.groups.yahoo.com/gro.../message/83855

J'ai dis je pense pour Les UNION, les AGRREGATIONS et les DISTINCT car en le lisant, du coup je n'avais pas bien interpréter le post en anglais.

Et lorsque j'ai réduit le nombre d'aggrégat dans la PS cela à fonctionner. Donc ils sont pris dans le compte.

Envoyé par Barbibulle;

J'aimerai bien trouver la requête qui permettrait de calculer ce nombre.

Je la cherche aussi.

[Barbibulle]

Je viens de faire quelques tests :

Une vue V1 compte pour 1 + le nombre de table dépendantes.

Mettons que la vue V1 soit une jointure de 10 tables, faire appel à cette vue va utiliser 11 context/relation.

Créons maintenant un procédure P1 basée sur cette vue V1 (un simple FOR select ... from V1 into :... DO suspend; de cette vue.)

L'appel à cette procédure P1 n'utilise 1 context/relation.

Apparemment les VUES sont consommatrices de contexte/relation alors que l'appel à une procédure ne coute qu'un contexte/relation.

[Barbibulle]

Envoyé par freud

Voici dans ce lien, ce que dis Yemanov, un des developpeur de FB, dans un topic, en réponse au même problème :
http://tech.dir.groups.yahoo.com/gro.../message/83855

Ca confirme ce que j'ai expérimenté !

Les vues consomment alors que les PS ne comptent que pour 1.

[TryExceptEnd]

La solution est de factoriser son code et de créer des "sous-procedures" qui exécutent une partie du code.
Mais je le répète, a moins d'avoir une base mal conçu et/ou d'écrire son code SQL comme on écrit en BASIC, il n y a rien a craindre de cette limitation.

[Barbibulle]

Envoyé par TryExceptEnd

Mais je le répète, a moins d'avoir une base mal conçu et/ou d'écrire son code SQL comme on écrit en BASIC, il n y a rien a craindre de cette limitation.

Ca peut arriver assez vite en utilisant pas mal de vues complexes.

Ca me rassure car dans mes PS je n'utilise que des appels directs aux tables ou à des PS. Jamais à des vues.

[freud]

Envoyé par Barbibulle

Ca peut arriver assez vite en utilisant pas mal de vues complexes.

C'est mon cas et suis parti du principe que l'on peut utiliser une vue comme une table et comme c'est des vues jointées contenant des IIF's, j'ai penser (paresse oblige ) qu'il serais plus simple pour moi d'appeler une vue qui me fournira des informations de plusieurs tables qu'elle jointe que d'appeler les tables en questions.

Envoyé par TryExceptEnd

La solution est de factoriser son code et de créer des "sous-procedures" qui exécutent une partie du code.

C'est effectivement la seule issue, je vais coupé la procédure SP_TRANSFORM_PIECE en :

1) SP_TRANSFORM_PIECE_VENTE
2) SP_TRANSFORM_PIECE_ACHAT
3) SP_TRANSFORM_PIECE_STOCK

Et d'eviter de faire appel trop souvent à des vues complexes.

[freud]

La solution finale que j'ai adopté pour la PS, consistait à remplacer certaines vues consommatrices (et pas toutes) par des tables donc inutile de factoriser en coupant la PS en plusieurs parties, pour la simple raison que le problème initial était une utilisation abusive de certaines vues sans connaissance de cette limitation.

Envoyé par Barbibulle

Ca me rassure car dans mes PS je n'utilise que des appels directs aux tables ou à des PS. Jamais à des vues.

Mais rien n'interdit de faire appel aux vues dans les PS. Une vue c'est également une table. Parfois ça aide beaucoup notamment pour pour les vues updatetable. Il suffit de gérer cela.

Par contre, il serait intéressant de savoir le pourquoi de cette limitation à 225 dans FB 2 et de 127 dans FB 1 et si dautre SGBD's comme Oracle, PostGres,..., la pratiquent.

[TryExceptEnd]

Envoyé par freud

La solution finale que j'ai adopté pour la PS, consistait à remplacer certaines vues consommatrices (et pas toutes) par des tables donc inutile de factoriser en coupant la PS en plusieurs parties, pour la simple raison que le problème initial était une utilisation abusive de certaines vues sans connaissance de cette limitation.

Si tu remplace une vue par la requête qui génère cette même vue, je ne vois pas trop l'utilité.
Sinon, ce qui est fondamentale est d'avoir bien conçu sa base donnée, bien normalisée celle-ci... le reste couleras de source.

[freud]

Envoyé par TryExceptEnd

Si tu remplace une vue par la requête qui génère cette même vue, je ne vois pas trop l'utilité.

Bien sûr que oui c'est inutile mais ce n'est pas le cas.