Re: What Am I missing?

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.

William

On 8 Sep 2020, at 14:32, Jeff Smith <jeff.d.smith_at_oracle.com> 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 <william_at_williamrobertson.net <mailto:william_at_williamrobertson.net>> Sent: Tuesday, September 8, 2020 9:05 AM To: oracle-l <oracle-l_at_freelists.org <mailto:oracle-l_at_freelists.org>> 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.  

William      

On 8 Sep 2020, at 10:40, Sayan Malakshinov <xt.and.r_at_gmail.com <mailto:xt.and.r_at_gmail.com>> 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 <william_at_williamrobertson.net <mailto:william_at_williamrobertson.net>> 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 19.0.0.0.0.  

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

William  

--

Best regards,
Sayan Malakshinov
Oracle performance tuning engineer
Oracle ACE Associate
http://orasql.org <https://urldefense.com/v3/__http:/orasql.org/__;!!GqivPVa7Brio!LYx56aAY5ou-8eqHz36a2fyLZpAGooxrx5dCKv8A7WYnocQMEasvJ5_uz4f7qUUmg6s$>

--

http://www.freelists.org/webpage/oracle-l Received on Tue Sep 08 2020 - 15:49:17 CEST