Échapper à l'esperluette dans PL / SQL Developer
J'essaie une simple instruction INSERT contre une base de données Oracle. L'une des valeurs est un champ VARCHAR2 et l'instruction insert contient une esperluette. Comment dois-je faire? J'ai essayé les méthodes suivantes:
- échapper le & as & avec set escape sur
- Désactiver l'analyse (cela provoque une erreur d'option Ora-00922 manquante ou non valide)
- set define off (ceci provoque une erreur d'option Ora-00922 manquante ou non valide)
D'autres idées?
7 réponses
Comment je l'ai résolu échappe au & avec un autre &.
Par exemple:
INSERT INTO Foo (Bar) VALUES ('Up && Away');
Fonctionne bien. Merci pour toute l'aide
La version actuelle de PL / SQL Developer (11.0.x) a un bouton pour désactiver / activer les variables de substitution.
L'une des caractéristiques de PL/SQL Developer dont il faut du temps pour se familiariser avec est la pléthore de différents types de fenêtres.
L'un d'entre eux est la fenêtre de commande, qui est essentiellement un émulateur SQL*Plus. Nous pouvons exécuter des commandes SQL*Plus ainsi que SQL, donc SET ESCAPE, SET DEFINE et en effet SET SCAN OFF travailler dans cette fenêtre.
Avez-vous essayé quelque chose comme ça?
INSERT INTO tablex VALUES ('Sid ' || '&' || ' Nancy');
En améliorant ma première réponse, votre problème est lié à PL / SQL Developer. Si vous exécutez votre bloc dans une fenêtre de commande de développeur PL/SQL, vous pouvez également utiliser L'ensemble standard DEFINE OFF, qui fonctionne de la même manière que dans SQL * Plus.
Le concat a parfaitement fonctionné pour moi ci-dessous est ce que j'ai fait dans ma déclaration select:
select FUND_NM
FROM PERFORMANCE
WHERE upper(FUND_DESC) in ('My L&' ||'L FUNDS')
J'utilise chr(38) où j'ai besoin d'une esperluette en PL/SQL.
addr:= 'mysite.com/order.aspx?no=5678' || CHR(38) || 'id=947';
--above line gives you 'mysite.com/order.aspx?no=5678&id=947';
Ceci est juste un problème D'éditeur SQL. Pour résoudre ce problème, il suffit de compiler la procédure avec SET DEFINE OFF;. L'exécution qui est PL (s'exécutant dans le serveur) ne rencontrera pas ce problème.