Je rencontre Oracle 11g sur Linux et j'essaie d'exécuter un script qui créera ma base de données. Ce script fonctionne bien sous Windows, mais lorsque je le teste sur Linux, je reçois l'erreur suivante:
more "../database/My Schema/create_sequence.sql"
7 Réponses :
Avez-vous essayé d'échapper à l'espace blanc?
Essayez: P>
sqlplus [uname]/[pw] @'../database/My\ Schema/create_sequence.sql'
J'ai essayé cela (avec et sans les citations englobantes, célibataire et double), et je reçois la même erreur "SP2-0556: Nom de fichier non valide"
Avez-vous essayé de faire le nom complet du chemin plutôt que ../database/ ..?
Lorsque j'utilise le nom complet du chemin, je reçois la même erreur, si l'espace est échappé ou que tout le chemin / le nom de fichier est enfermé dans des guillemets.
Cela pourrait être un coup long, mais qu'en est-il des autorisations de fichier sur Create_Enfense.SQL?
L'utilisateur que je fonctionne comme possède le fichier. De plus, lorsque je change le nom du répertoire de mon schéma vers MySchema, le script est exécuté. Je sais que la solution facile est de renommer tous les DiRs pour ne pas avoir d'espaces dans eux, mais je cherche une solution plus flexible /
Je comprends complètement que c'est pourquoi je n'ai pas suggéré de changer le nom du dir. Eh bien, je suis à court d'idées, désolé je ne peux pas être d'aide plus d'aide.
Si vous travaillez avec ce sous Linux, vous pouvez échapper à l'espace avec un caractère '\' comme tel:
J'ai essayé cela (avec et sans les citations englobantes, célibataire et double), et je reçois la même erreur "SP2-0556: Nom de fichier non valide"
Remarque côté: exécutez une commande comme: plus ../ base de données / mon \ schéma / create_frence.sql ou plus "../database/my schéma / create_freence.sql" imprime le contenu du fichier à la console comme on peut s'y attendre. Donc, je pense que c'est SQLPlus spécifique.
Eh bien, s'il s'agit d'une question Linux (voir mon commentaire sur votre question - cela fonctionne bien sur Solaris), vous devrez peut-être essayer quelque chose sur les lignes de: vous exécutez Dans les problèmes si vous essayez de passer des paramètres à votre script SQL, toutefois ... p> EDIT: Il semble y avoir une question Metalink soulevée pour un problème très similaire: "Bug 7150873 Scripts SQL avec nom de fichier contenant Les espaces ont des résultats dans SP2-0556 ". Il est inscrit comme affectant 10.2.0.4 et 11.1. Il est censé être corrigé dans 10.2.0.5 et 11.2, ni non plus disponible. Il dit que c'est une question générique affectant la plupart des plates-formes, donc je ne sais pas si ceci est votre problème ou non. P> Le texte spécifique du problème: "La commande SQLPLUS START échoue à exécuter SQL scripts qui ont un espace dans le nom de fichier. " P> Juste pour les sources, que se passe-t-il si vous faites ce qui suit: p> EDIT2: je ne sais pas Sachez si la modification de vos scripts en gros est réalisable ou non, mais une solution de contournement peut être: p> Vous auriez besoin d'envelopper chaque appel SQLPLUS de cette façon. Une autre option serait de créer un script shell, par exemple avec un nom de mysqlplus.sh:mysqlplus.sh [uname]/[pw] '../database/My Schema/create_sequence.sql'
Si près ... cela fonctionne, mais je dois pouvoir utiliser la syntaxe @ en raison de la manière dont nous utilisons ces fichiers pour déployer la base de données.
J'apprécie les informations supplémentaires sur le bogue car je n'ai pas accès à metalink. On dirait que c'est le problème.
Si j'avais les points REP, je voudrais +1 ceci :-) Merci pour l'effort!
Selon Ce fil sur le site OTN, SP2- 0556 peut être causé par des caractères d'espace blanc non valides dans le fichier en cours d'exécution. Probablement la version Linux de SQL-Plus ne sait pas comment traiter avec Windows Newline Caractie (s). Essayez de supprimer le fichier existant et de le recréer avec vos commandes souhaitées (vous avez dit qu'il n'y a que 2 commandes DDL afin qu'elle soit facile).
même erreur. N'oubliez pas que cette même commande exacte fonctionne si j'ai renommé le répertoire de «mon schéma» à myschema et modifiez la commande afin de cela ressemble à ceci: SQLPlus [UNAME] / [PW] @ '/ MySchema / Create_SeDence.SQL' Donc, je ne pense pas que ce soit un problème avec le fichier ou les commandes dedans.
Yup, j'ai oublié ce détail. La réponse est toujours un bon rappel que Windows et * Nix traitent avec des lignes neuves différemment.
J'ai connecté à l'une de mes boîtes Linux et était assez facile à reproduire ce problème. Il ne semble pas y avoir de moyen que je puisse trouver pour exécuter le fichier avec l'option '@' à partir de la ligne de commande, de sorte que je pense que vous êtes resté à l'aide des options suivantes pour les circonscriptions de travail:
Vous devez également déposer un rapport avec Oracle Support car il peut y avoir une solution simple qu'elles peuvent fournir. p>
Exemple de commande: p>
de répertoire p >
sqlplus [uname]/[pw] < ../database/My\ Schema/create_sequence.sql
Je suis venu à cette même conclusion. On dirait que c'est un bug qui peut être corrigé en 11,2 (ht: dcookie ci-dessous), mais je ne peux pas attendre cela. De plus, il est probablement plus facile de modifier ma structure de répertoire que d'exiger 11.2 sur 11,1 en raison d'une solution de bogue obscur ...
Si vous mettez des citations autour du chemin, cela fonctionne:
SQL > START C:\Documents and Settings\Administrator\demobuild.sql
Ne fonctionne pas ici avec des citations doubles ou citations simples.
En outre, la question était concernant Linux. Pas Windows.
Je sais que c'est une question ancienne, mais je viens de courir dans la même situation et après beaucoup d'essais, je l'ai fait travailler et je veux partager ma solution, c'était simplement mettre le chemin dans des citations comme celle-ci:
@ "c: / users / john / appdata / itinérance / sql développeur / test.sql";
Cela ne fonctionne pas pour moi. Il dit SP2-0310: impossible d'ouvrir le fichier . Mais le fichier existe (je peux, par exemple, avec succès type it)
Je viens de courir un test en utilisant votre syntaxe d'origine sur une boîte Solaris et cela fonctionne très bien.
Oracle a un binaire différent pour Solaris que Linux. Et mes commandes fonctionnent sous Windows, mais pas Linux. Je suis légèrement surpris que cela fonctionne sur Solaris depuis que je suppose que le code source est plus proche de Linux.
En regardant le rapport de bogue que j'ai noté, cela m'a eu lieu que cela a probablement fonctionné car il s'agit d'un environnement de base de données 8I et que l'insecte a recadré 10 g et reporté à 11g.