Can Goland autocomplete SQL statements using other SQL packages? - sql

Goland is great at auto-completing SQL statements if I use the sql.DB package functions.
For example, Goland will provide SQL autocompletion (including DDL data) in this setting:
result, err := someDB.Exec(`INSERT INTO <cursor here>`)
Can I configure Goland to show me SQL autocompletion in other contexts? For instance, I'm using github.com/jmoiron/sqlx and it has functions of the form:
err := someDB.Get(&user, `SELECT * FROM users WHERE email="%s"`, email)
In this second example, autocompletion wasn't triggered.
I can't find where/if this is configured in the Goland settings. Can I tell Goland which function parameters should be eligible for SQL autocompletion?

You can use Alt + Enter inside the query and then use Inject Language and start typing the SQL dialect that you want to insert.

Related

SAP HANA SQLScript in DBeaver

I would like to ask if anyone has any idea/ know how to use SAP HANA SQLScript in DBeaver.
Since SAP HANA supports some very useful features such as table variables etc, I would like to run following code (just a quick example):
do BEGIN
DECLARE lv_id INT;
lv_id = 100;
lt_test = SELECT id
FROM some_table
WHERE ref_id < :lv_id;
SELECT * FROM some_other_table
WHERE from_id IN (SELECT id FROM :lt_test); END;
but unfortunately it will give some error messages
sql syntax error: incorrect syntax near "NULL": line 13 col 35 (at pos 174)
Does anyone know if there is anything that can be done so this code will work in DBeaver without the need of going into SAP Web IDE or HANA Studio all the time?
Maybe someone also knows any other good IDE with features like code completion, etc., for SQL that works well with HANA (other than Web IDE and HANA Studio)...
The "trick" here is to select the correct handling of bind parameters in DBeaver.
When a SQL command with strings that look like bind parameters should be executed, DBeaver presents a dialogue window:
In this window, one can specify how the bind variables should be handled.
As the SQLScript variables are not bind variables (i.e. the client does not bind values to them) the correct selection in this window is to IGNORE the bind variables.

Syntax highlight SQL queries when using non-standard SQL packages in Goland IDE

When using Goland it is very useful to get SQL syntax highlight and autocompletion based on my connected datasources. Unfortunately this only seems to work when I'm using the standard Go sql package and does not work when I use custom packages that effectively wrap the sql package calls. I was wondering if it's possible to tell Goland that specific functions / parameters are actually SQL queries / SQL statements.
Here's an example of Goland allowing SQL completion for methods on sql.DB struct vs not allowing completion on custom query.ReadOnlyDB struct:
Currently, you can specify //language=SQL comment before the statement:
package main
import "fmt"
func main() {
//language=SQL
str := "SELECT USERNAME FROM EXAMPLE"
fmt.Println(str)
}
There are a few tickets to improve SQL highlighting in GoLand and you can follow them:
GO-10398. SQL highlighting for custom packages/proxies.
GO-10011. Inject SQL automatically to strings that start with SQL queries (SELECT, CREATE, DELETE, and so on).

Intellij 2016.3 update to Oracle 12c syntax

After a recent upgrade to Oracle 12cR1, Idea's database-editor syntax-highlighting has gotten out-of-date for my Oracle connections.
Queries making use of 12c syntax that work fine in SQLPlus(12.1.0.2.0) and SQLcl(4.2.0) highlight as incorrect syntax in my Idea editor. They also fail to run when executed from the editor.
I'd like to update intellij, but I haven't found where to upgrade the oracle dialect and my jdbc drivers appear to be up-to-date. I was hoping for advice on two fronts--where to upgrade intellj to successfully execute 12c-syntax SQL, and how to get Idea's Oracle-Dialect to have 12c-compatible syntax highlighting. An example that would cover both of these is subquery-factoring-clause function-declaration. These constructs fail to execute for me in the editor with an ORA-06553.
I'm on Ubuntu-16.04 LTS with Idea (v 2016.3.4)
I'm using Database-Plugin: Database Tools and SQL plugin (v 1.0)
I'm using the provided drivers: .IntelliJIdea2016.3/config/jdbc-drivers/
Driver-versions are xdb6-12.1.0.2.jar and ojdbc6-12.1.0.2.jar
I'm not currently using any additional files in my driver configuration
If this isn't supported yet, I can accept that. I'd just like to upgrade if currently possible.
Thanks
Here's an example for checking whether a string is on the (dvorak) home-row for typing. The statement works fine in SQLPlus and SQLcl, but is flagged as invalid in Idea and fails to execute (ORA-06553). This could of course be done more succinctly with SQL only, but hopefully illustrates the issue.
WITH
FUNCTION IS_IT_DVORAK_HOME_ROW(P_CHAR_STRING IN VARCHAR2 )
RETURN NUMBER
IS BEGIN
CASE WHEN REGEXP_LIKE(P_CHAR_STRING, '^[AOEUIDHTNS-aoeuidhtns_ ]{1,}$')
THEN RETURN 1;
ELSE RETURN 0;
END CASE;
END;
SELECT DECODE(IS_IT_DVORAK_HOME_ROW('This And That And These and Those Too'),1,'Home-Row!','Nope...') AS HOME_ROWNESS
FROM DUAL;
/

What is this Oracle SQL Syntax ${}?

I have an oracle query which has a select statement
select table.columnname = ${sometext_sometext_sometext}
I would like to know what is the purpose of ${}.
Also this throws an error in Oracle SQL developer. Kindly advise what is the work around.
This isn't Oracle syntax, this is a common syntax for interpolating variables into a string found in Perl, Groovy, and a bunch of other languages.
You don't say what the context is here, but what is probably going on is something modifies the file, probably with environment-related properties, before the SQL gets run, the ${} is there to identify to the modifying script what value to substitute here. This is a common thing to do when you have environment-specific properties that need to be injected into a SQL script.
Can you give some background as to where you got this SQL statement? It appears that you are working with a query that requires pre-processing via Java, PHP, a Bash shell script, etc. Standard Oracle SQL or PL/SQL does not know what to do with the "${}" syntax.
I have used this syntax in a standard SQL template that I then process in Java or a bash shell script to generate the final SQL statement.

Can I prepare a statement in plain Oracle SQL?

3GLs provide mechanisms to prepare statements before executing them. E.g.
SELECT name
FROM people
WHERE age=:AGE
The same query can then be executed for different ages. But can such a statement also be prepared in a "plain" Oracle SQL client? Can the same be done in e.g. SQL Plus or dbForge Studio for Oracle as in Java or C# or any other programming language that supports prepared statements?
In dbForge Studio for Oracle, named parameters can be used, preceded by a colon :
SELECT *
FROM people
WHERE name=:name
The parameters can then be filled in with the "Edit parameters dialog box", available from the SQL toolbar.
I know you didn't ask about PostgreSQL but about Oracle. However, of note, PostgreSQL has this feature right in its SQL language.
The SQL standard includes a PREPARE statement, but it is only for use in embedded SQL. The PostgreSQL version of the PREPARE statement works like this:
PREPARE nameByAge(number) AS
SELECT name
FROM People
WHERE age=$1;
and you use it like this:
EXECUTE nameByAge(18);
EXECUTE nameByAge(50);
So unfortunately for Oracle SQLPlus the answer seems to be no, not bind variables. But SQLPlus has substitution variables, similar to shell scripts. You use them as &1, &2, &3, ... and they get their parameters from the way you call the SQLPlus script.
sqlplus user/password #script.sql 18
sqlplus user/password #script.sql 50
with the script.sql being
SELECT name
FROM People
WHERE age=&1;
this would work, even though it is not bind. But then, do you really care about the slight savings in repeat parse time? In fact Oracle hashes SQL statements and already replaces constants with bind variables to be able to better reuse query plans. So the savings you would get with PREPARE and BIND are really minuscule.