Discussion :

[star]

J'ai un package specification dans lequel j'ai une déclaration de type et une pour une fonction:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SUBTYPE services_record_type IS services%ROWTYPE;
 
FUNCTION services(services_record IN OUT services_record_type) return BOOLEAN;

Lorsque je compile, l'erreur suivante m'est donnée:

Error 310 with %ROWTYPE attribute. 'SERVICES' must name a table, cursor or cursor-variable.

Auriez-vous rencontré cette erreur et quelle pourrait-être la solution ?
Merci pour votre aide.
.

[heffer69]

Il ne reconnaît pas la table 'services'. As-tu tous les privilèges sur cette table?

[star]

J'ai accès à la table services sans problème.
J'ai essayé avec le nom du schéma:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SUBTYPE services_record_type IS star.services%ROWTYPE;

et là ça compile.
Mais j'aurais souhaité passer par un synonym public plutôt que d'utiliser une référence absolue 'nom de schéma.nom de table'.
J'ai aussi pensé modifier le nom de la fonction services et là aussi ça compile.
Mais bon, avec Forms 4.5 je n'avais ce problème.
Pourquoi avec la 10g ça ne marche plus ? J'ai cherché dans la doc et les white papers et la seule explication que j'ai trouvé c'est que dans les specs d'un package, il n'est pas possible d'avoir une fonction ayant le même nom qu'une variable. Sauf que dans mon cas, il s'agit d'une déclaration de type.
.

[star]

Je souhaiterais vous "ressoumettre" le problème que j'exposais dans mon post du 15/7/2005 et qui est resté sans solution depuis.

Dans l'aide en ligne d'Oracle Forms Developer, il est écrit :

Unique Names Required within a Package

In PL/SQL V1, when you created a variable with the same name as a procedure or function in the same package, the variable was always used; the identically named procedure or function was ignored. In versions after V1, variables, functions, and procedures within the same package must be unique.

To avoid an error, make sure all procedures within a package have unique names, either by doing so explicitly, or by appending the word Unused to the procedure name.

Dans le White Paper : Upgrade Developer Forms 4.5 to Oracle Forms 6, il est mentionné :

VARIABLES AND PROGRAM UNITS WITH SAME NAME IN SAME PACKAGE

It is no longer legal to have program units and variables with the same name in the same package.
The compiler cannot resolve which to reference. Whith PL/SQL V1 you may have gotten unexpected results at runtime, meaning that while coding you may have meant to reference the value of a variable, but intead got the return value of a function whit the same name.
Oracle recommends prefixing all variable whith a 'v_'.

Pour revenir au problème que je rencontre, il semble que Forms Builder assimile une déclaration de type comme étant une déclaration de variable ou de procédure et applique la même restriction dans le nommage des objets.

Pourtant nulle part dans la doc il est dit que cette restriction s'applique à une déclaration de type ???

Pourriez-vous m'aider ?
Merci
.

[plabrevo]

Mais j'aurais souhaité passer par un synonym public plutôt que d'utiliser une référence absolue 'nom de schéma.nom de table'

Sur. Mais ne pourrais-tu pas tout de meme creer un synonyme 'starservices' pointant sur star.services et le referencer comme ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
SUBTYPE services_record_type IS starservices%ROWTYPE;
 
FUNCTION services(services_record IN OUT services_record_type) return BOOLEAN;

[star]

Oui c'est une solution.
Mais pour se faire, il va falloir que je double tous les synonymes (starservices et services pour la table services, etc.) sur toutes mes tables et que je modifie toutes les références aux synonymes pour utiliser les nouveaux dans toutes mes librairies et packages (300),.
Un peu pénible quand même ! je risque d'y passer du temps et le temps s'est de l'argent !
Non, franchement je touve que ça fait bricolage pour de la production.
Il manque vraiment pas d'air chez Oracle !
D'abord, il n'en parle pas du tout dans la doc de référence, il faut deviner, et en suite système D (démerde-toi).
N'y aurait-il pas moyen de faire remonter ça chez eux pour qu'il rectifie le tir ?
Merci de ton aide plabrevo, elle m'est très utile.
.

[plabrevo]

Je pense qu'une erreur de compilateur est preferable a un comportement aleatoire au runtime, donc la modification va dans le bon sens.

La creation des 300 synonyms devrait prendre de l'ordre de 15 minutes et un peu plus pour la packager. Bien evidemment il faudra un peu plus de temps pour modifier les librairies.

[star]

On me suggère par ailleurs de renommer ma fonction services en un autre nom, comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SUBTYPE services_record_type IS services%ROWTYPE;
FUNCTION starservices(services_record IN OUT services_record_type) return BOOLEAN;

Entre créer un synonym starservices pour ma table star.services ou bien renommer ma fonction services en starservices, lequel des deux pour vous serait le mieux ?

J'hésite ! Je dois certainement oublier ou rater quelque chose !
Auriez-vous des idées ?
.

[plabrevo]

Une troisieme solution serait de migrer ces packages sur la base de donnees.

Plus cher et peut-etre plus long a realiser, mais sans doute plus perenne, car reutilisable a partir de la plupart des technos outils.

[plaineR]

Une troisieme solution serait de migrer ces packages sur la base de donnees.

A condition que le package n'utilise pas des fonctionnalités propres à forms

Sans hésiter, je renommerai la fonction, je ne trouve pas très propre (ni très lisible) d'avoir une fonction qui a le même nom qu'une table.

[SheikYerbouti]

Sans hésiter, je renommerai la fonction, je ne trouve pas très propre (ni très lisible) d'avoir une fonction qui a le même nom qu'une table.

+1

[star]

Une troisieme solution serait de migrer ces packages sur la base de donnees.

J'ai migré les spécifications de mon package dans la base, mais bon, je rencontre la même erreur et la même restriction dans la définition de mon SUBTYPE.
Donc ta 3ème solution ne règle en rien le problème !
Merci quand même.
.

[plabrevo]

ok. J'avais d'abord pense que l'erreur provenait d'un conflit de nom au sein du meme package avec l'espoir de voir le PL 9i ou 10g plus tolerant sur le sujet.
Si la syntaxe est rejetee meme en 9i ou 10g, le type pourra etre cree en tant qu'object (CREATE OBJECT <>). Une autre premiere solution est de creer le (sub)type avec une instruction RECORD plutot que ROWTYPE. Une autre de referencer directement les datatypes avec table%ROWTYPE.

[star]

Une autre premiere solution est de creer le (sub)type avec une instruction RECORD plutot que ROWTYPE.

Pour la maintenance du code, c'est pas terrible !
Tout changement dans la structure de mes tables m'obligerait à devoir répercuter la modification manuellement dans tout le code !

Une autre de referencer directement les datatypes avec table%ROWTYPE

Avec le nom du schéma en préfix : SchemaName.TableName%ROWTYPE ?
J'ai déjà essayé, ça compile mais bof !
Je perd tout l'interêt des synonymes...

Il me reste le CREATE OBJECT. Je vais essayer mais je connais pas la syntaxe !
Pourrais tu me donner un exemple qui collerait à mon cas ?
Merci d'avance
.

[plabrevo]

Il y a un typo plus haut. Je voulais parler d'un CREATE TYPE as OBJECT.

Example de CREATE TYPE:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
CREATE TYPE mytype AS OBJECT
(id      INTEGER
,n1      INTEGER)
/