IDE "error" due to ORACLE SQL-statement with bind variables

Answered

Hi,

in my go-Code I have the following function:

func (a *App) StmtSelectMengen() string {
var stmt = `
SELECT Ort, Menge
FROM Gebinde
WHERE Tag = :1 and LVS = :2
`
return stmt
}

SQL dialect is ORACLE. The code also works:

However it is marked red with the error:

<hierarchical query clause>, FETCH, FOR, GROUP, HAVING, INTERSECT, MINUS, MODEL, OFFSET, ORDER or UNION expected, got '1'
Identifier expected

The IDE does not like the :1 bind  variable. How to resolve the "pseudo error" or how to disable  this kind of errors would be good.

Thomas

0
5 comments

Hi Thomas,

Feel free to follow DBE-4033.

You can use single quotes for bind parameters e.g. :'1' until we implement an IDE-wide solution.

0

Hi Daniil,

I'm also having some issues in IntelliJ with the same kind of bindings.

Why is there no way to at least turn off the inspection for this false error? This has not happened in the previous version, as far as I can tell.

It does not seem like your suggestion of :'1' is making any difference (and I'm not really sure if this is a valid syntax). And I think ':1' would definitely be wrong.

Is there an actual issue for this in the tracker or should we create one?

Thanks,
Manuel

0

You can suppress any inspection for the needed scope (hit Alt+Enter with the caret on the problematic part):

0

Hello Sergey,

Thanks for the suggestion, this usually works for other errors, but not for this one:

Unfortunately there doesn't seem to be a "Suppress.." option for this case. I guess it's something else than the usual inspections?

This makes it hard to tell if there are any actual errors in the file, without compiling first.

0

Update: I managed to fix this by using alphanumeric bind variables instead of numeric ones, so you can use something like :first, without the IDE showing any errors (and the business logic seems to remain the same). The named vars are not really useful because they will be bound in order of the supplied parameters, but this is a limitation of go-ora I think.

0

Please sign in to leave a comment.