Strange delimiter behavior parsing the file in the wrong area

[markoueis]

The default oracle delimiter for multiple statements is /
However this should obviously not cause the file to split on / if the / is used in some sort of math division. I'm seeing it incorrectly parse a large file at this line here

l_amount := mv_round_amount(l_amount_to_dist*(l_pct/100),trans_rec.currency_id);

What's going on here? This seems so basic that I feel I must be doing something wrong, but this is indeed what is happening.

It doesn't seem to parse on / if the / is in comments or in strings. What's going on here? How can i move forward.

From what i can tell the parsing logic is implemented in dbup and not in dbup.oracle which is why i'm posting this here.

[markoueis]

To simplify it, this test fails

[Fact]
public void CanParseMultilineScript()
{
var multiCommand = "create table FOO (myid INT NOT NULL)/";
multiCommand += Environment.NewLine;
multiCommand += "create table BAR (myid INT NOT NULL, myNum INT NOT NULL DEFAULT**(10/2)**)";

   var connectionManager = new OracleConnectionManager("connectionstring", new OracleCommandSplitter('/'));
   var result = connectionManager.SplitScriptIntoCommands(multiCommand);

   result.Count().ShouldBe(2);

}

[Orkad]

Same problem for trigger creation with ";" the only thing you can do is to use the custom keyword DELIMITER ; before the division to change the current SQL command delimiter in the file. I'm sure the SQL splitting behavior could be improved.

[utilpros-jgreisz]

Seems like this has not been fixed. I switched to a delimiter of ASCII 254 which solved the problem. Now if I could only figure out how to get feedback like the SQL Server print that's in scripts I am migrating.

[jhopkinscdcr]

This is still not fixed. I confirmed with the latest as of 9am on 10/20/2025. The SqlParser doesn't consider the context of the found forward slash delimiter which is leading to valid division operators within Oracle PL/SQL being interpreted as the end of the PL/SQL block. utilpros-jgreisz's work-around will work but making the parser context aware would eliminate the need for the work-around.

The issue is with the dbup SqlParser which doesn't parse the code with a respect to the context operators are used in. There is a custom statement implementation within the dbup-oracle code, but the dbup SqlParser needs to be augmented to track the context of the parsed code. The parser would then know if the forward slash is a division operator within a code block or a delimiter as the end of a block.

Dbup doesn't break the code when the forward slash is within a single or multi-line comment because the parser skips over any text once a comment operator is detected until the end of the line for a single line comment or the end of the multi-line comment operator is detected. This technique will not work for the delimiter because the only method to skip a delimiter is to know whether the delimiter is being used within a code block or not. For SQL Server, the delimiter 'GO' is a keyword and isn't valid within Transact SQL blocks without being within quotes (which is handled in dbup), within a comment (which is handled), or as part of a larger word (which is handled).