Re: What Am I missing?

From: William Robertson <>
Date: Tue, 8 Sep 2020 14:49:17 +0100
Message-Id: <>

Absolutely, scripts should tested using whatever tool is used for deployment, ideally automatically using Team City or similar. I have a "Run with SQL*Plus" tool defined in my menu bar. I think this is possible with all the main IDEs. I'd just say that an IDE is not generally a practical tool for automating deployments, and a CLI is not much use for interactive development, so two separate tools are pretty much inevitable.

I've heard a lot about Liquibase, though I haven't used it, but now I'm wondering if there is some way to accidentally glitch that as well.


On 8 Sep 2020, at 14:32, Jeff Smith <> wrote:

Using one tool to build said scripts and using another tool to deploy said scripts is a recipe for…bad things.  

Your devs should be testing everything with SQL*Plus if that’s how their code ends up in the real world.  

From: William Robertson < <>> Sent: Tuesday, September 8, 2020 9:05 AM To: oracle-l < <>> Subject: Re: What Am I missing?  

That will work in this particular case, assuming the script contains exactly one object definition and nothing else, and we don't mind losing blank lines.  

But I can create the function in PL/SQL Developer anyway, so the problem only arises when the source code file is run using SQL*Plus as part of a deployment. If we have some deployment framework that calls SQL*Plus and we change it to get & run everything, it will then fail on other scripts that contain multiple statements. Or if we change this particular script to get & run itself that could work, but it would be less effort just to move the slash character, and we would still have our blank lines.  

Anyway the point I was making was that it's unfair to blame the PL/SQL parser, which I felt was somewhat implied by "It's a PL/SQL parser bug." It's more of a limitation of a CLI that needs a "stop input and execute" character which happens to be the same as a language operator. You’d hit the same issue with a SQL statement.  


On 8 Sep 2020, at 10:40, Sayan Malakshinov < <>> wrote:  

Hi William,  

As I said previously that's just a problem of command processing with pretty easy workaround: just save your ddl as a script and use `get file.sql` command to put its content into the buffer and run using /  

On Tue, Sep 8, 2020 at 12:34 PM William Robertson < <>> wrote: I wouldn't call it a PL/SQL parser bug. The client tool doesn't know it's PL/SQL and splits the code at the / character, producing an incomplete function followed by some unparsable lines which never reach the PL/SQL compiler. I'm amazed that I've never seen this before but I can reproduce it in SQL*Plus  

I'm not sure what else SQL*Plus could do, to be honest, as / means run and there is no way to change it.  



Best regards,
Sayan Malakshinov
Oracle performance tuning engineer
Oracle ACE Associate <;!!GqivPVa7Brio!LYx56aAY5ou-8eqHz36a2fyLZpAGooxrx5dCKv8A7WYnocQMEasvJ5_uz4f7qUUmg6s$>

-- Received on Tue Sep 08 2020 - 15:49:17 CEST

Original text of this message