I am trying to build a recursive Stored Procedure in DB2 PL SQL. But a little late in the game did I realize that it would throw an undefined reference error. So is recursion not possible in DB2 PL SQL?
From the IBM Devworks by Serge Rielau and Rick Swagerman
There are multiple ways in which DB2 supports recursion in SQL. One of
which is recursion using the ANSI SQL recursive UNION ALL approach.
The other approach is using the CONNECT BY clause.
You need to use Modules or dynamic SQL according to this blog.
Related
Is it possible to migrate T-SQL Stored procedure to Postgres database of version prior to 11, in any way? I know CREATE PROCEDURE supported from Postgres V 11 and above. Is there any other way we can achieve the same thing as we do in T-SQL Stored Procedure. We are planning to move to Amazon Aurora which supports Postgress 10.6 now. I am new to Postgres. Any suggestion would be appreciated .
Unsurprisingly, it depends on what you are trying to do. For most things, you will be able to use functions instead of procedures. If your stored procedures require transaction management, though, you won't be able to do that without procedures.
I am working on writing a Spring Java program accessing data from Athena, but I found that Athena JDBC driver does not support PreparedStatement, does anyone have idea about how to avoid SQL injection on Athena?
Update: I originally answered this question in 2018, and since then Athena now supports query parameters.
Below is my original answer:
You'll have to format your SQL query as a string before you prepare the query, and include variables by string concatenation.
In other words, welcome to PHP programming circa 2005! :-(
This puts the responsibility on you and your application code to ensure the variables are safe, and don't cause SQL injection vulnerabilities.
For example, you can cast variables to numeric data types before you interpolate them into your SQL.
Or you can create an allowlist when it's possible to declare a limited set of values that may be allowed. If you accept input, check it against the whitelist. If the input is not in the allowlist, don't use it as part of your SQL statement.
I recommend you give feedback to the AWS Athena project and ask them when they will provide support for SQL query parameters in their JDBC driver. Email them at Athena-feedback#amazon.com
See also this related question: AWS Athena JDBC PreparedStatement
Athena now has support for prepared statements (this was not the case when the question was asked).
That being said, prepared statements aren't the only way to guard against SQL injection attacks in Athena, and SQL injection attacks aren't as serious as they are in a database.
Athena is just a query engine, not a database. While dropping a table can be disruptive, tables are just metadata, and the data is not dropped along with it.
Athena's API does not allow multiple statements in the same execution, so you can't sneak a DROP TABLE foo into a statement without completely replacing the query.
Athena does not, by design, have any capability of deleting data. Athena has features that can create new data, such as CTAS, but it will refuse to write into an existing location and cannot overwrite existing data.
I'm familiar with Oracle more so than DB2, I have a piece of JavaScript code that makes an Oracle (SQL) call that returns an explain plan, essentially a remote statement execution. From what I've read DB2 looks to be a little different in that there is a command line utility to generate the plan.
Is there a way to generate an explain plan via a remote call in the same way an SQL statement is prepared and executed?
Update:
I'm working in a hosted setup where to be honest I don't even know the version or platform for db2, I'm not sure if this will help but for Oracle we do this:
Statement stmt = con.createStatement();
stmt.execute("explain plan for "+sql);
rs = stmt.executeQuery("select * from table(dbms_xplan.display())");
This (in rs) gives me a textual explain plan that includes the cost of the query, I'm looking to do the same for a db2 database where I assume this syntax isn't going to work.
I have several table-valued overloaded procedures in my PostgreSql database. They have the same name, but different number of parameters. As JOOQ 3.5 treats those procedures as tables, generator discovers only one procedure with that name. Is it designed this way, or is there a workaround?
GeneratorStrategy doesn't help as this happens earlier, when database.getTables(schema) in Generator is Called.
This is a bug (#4055) in jOOQ 3.5.2. jOOQ currently doesn't support overloaded table-valued functions.
The only workaround I can think of is to resort to plain SQL for those functions.
A general question.
I am developing for Sybase SQL Anywhere 10. For backwards comptibility reasons, almost all our Stored procedures are written in Transact-SQL.
Are there any advantages or disadvantages to using T-SQL instead of the Watcom dialect?
Advantages of TSQL:
greater compatibility with Sybase ASE and Microsoft SQL Server
Disadvantages of TSQL:
some statements and functionality are only available in Watcom-SQL procedures. Some examples:
greater control over EXECUTE IMMEDIATE behavior in Watcom-SQL
LOAD TABLE, UNLOAD TABLE, REORGANIZE (among others) are only available in Watcom-SQL
the FOR statement for looping over the results of a query and automatically declaring variables to contain the values is very useful, but not available in TSQL
error reporting is less consistent since TSQL procedures are assumed to handle their own errors, while Watcom-SQL procedures report errors immediately. Watcom-SQL procedures can contain an EXCEPTION clause to handle errors
statements are not delimited by semi-colons, so TSQL procedures are more difficult to parse (and read). Syntax errors can sometimes fail to point to the actual location of the error
no ability to explicitly declare the result set of a procedure
no support for row-level triggers in TSQL
event handlers can only be written using Watcom-SQL
The documentation for SQL Anywhere T-SQL compatibility is available online. There are some database options that change behaviour to more closely match what you would expect from Sybase ASE. In addition, there are some functions that can be used to translate from one syntax to another.
Note that if you want to start adding statements in the Watcom dialect into an existing stored procedure, you will need to change the SP so that it is entirely written in the Watcom dialect. You cannot mix syntaxes in a SP, trigger, or batch.
What KM said - on the other hand, the "Watcom" dialect is much closer to ISO/ANSI-standard SQL, so that dialect is more likely to match to some other products and to appeal to people familiar with SQL standards.
if you ever try to port to SQL Server (or you go for a job on SQL Server), Sybase T-SQL is very close to SQL Server T-SQL. Sybase and MS joined up back in the day, so the core of those languages are very similar.