Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production Leigh.sql contains: INSERT INTO t1 VALUES ('fail bc semicolon The forward slash can be handled, as long as it is not alone on a line. As soon as sqlplus finds the character specified as sqlterminator, it ignores everything else and stops reading. The forward slash can be used in a string as long as it is not alone on a seperate line.
Next to that, sqlplus first scans for the sqlterminator and does this before scanning to the string terminator. Whatever you put in there, the forward slash is maintained as a free sqlterminator. For the examples you gave, your really chose the worst case. login.sql is executed during - surprising - login and is loaded from your SQLPATH or current directory. You can do most of this by using a login.sql. If that isn't possible, then perhaps there is a way to programmatically modify the scripts.
The best answer would be a way to allow these statements to run without modification by changing the environment in some way (as sqlblanklines does). I am aware that the sqlterminator can be changed and/or turned off, but both would require modifications to the code, the former moves the problem without resolving it and neither resolves the embedded slash issue. The blank lines are easy to resolve with a simple. Here is a worst case example containing multiple statements each with blank lines, semicolons, and forward slashes: INSERT INTO t1 VALUES ('aįor various reasons these statements need to be run from SQL*Plus. Occasionally I will get a script that will run fine in SQL Developer or Toad, but requires modification in order to be run successfully from SQL*Plus.
0 kommentar(er)
