I am trying to use HSQL for testing. In production, the code runs against a DB2 database. I would like to turn on the DB2 syntax of HSQL and run the production SQL against it (or as much of it as possible).
According to the documentation, in DB2 syntax mode, the nextval for expression is supported.
I've turned on DB2 syntax mode both with the connection property, sql.syntax_db2=true, and with:
set database sql syntax db2 true;
However, I am not able to use nextval for, though the syntax next value for works correctly:
values (next value for test_seq); -- returns the next value
values (nextval for test_seq); -- results in an error
The error is:
Error: user lacks privilege or object not found: NEXTVAL
SQLState: 42501
ErrorCode: -5501
Am I not correctly activating DB2 syntax mode, or am I doing something else wrong? I am logged in as SA, so can it be a privilege issue?
There is a mistake in the documentation. The DUAL table is supported the same way as in Oracle syntax, but NEXTVAL is an Oracle form used as test_seq.NEXTVAL.
The DB2 supports NEXT VALUE FOR test_seq and allows NEXTVAL as an alternative to NEXT VALUE. This will be supported in the next release of HSQLDB.
Related
When I try to use RAISE NOTICE in a Query tool in PgAdmin I just get "ERROR: syntax error at or near "RAISE"". This is stopping defining a stored procedure which uses RAISE NOTICE.
I have simply typed the following into a Query Tool window:
RAISE NOTICE 'Bob';
I am using PgAdmin 6.3 (the latest), just updated from v4.5 which had the same problem.
RAISE is part of pl/pgsql, Postgres's default procedural language. It is not available in a direct SQL context, or any function or stored procedure defined with LANGUAGE sql rather than LANGUAGE plpgsql.
If you're used to a different DBMS like MySQL or SQL Server, you might expect to have procedural code (variables, conditionals, loops, etc) available by default, but that's not how Postgres works. In order to use procedural code, you need to be inside a function, stored procedure, or DO statement.
Using the Keyword Query from the Robot Framework DatabaseLibrary JayDeBeApi in conjunction with DB2 like this: ${results}= Query CREATE TABLE SCHEMANAME.TEST_TEMP (id BIGINT, name VARCHAR(25)) is being executed (table exists afterwards).
But nevertheless RobotFramework throws a FAIL and ${results} contains the Message DatabaseError: com.ibm.db2.jcc.am.SqlSyntaxErrorException: DB2 SQL Error: SQLCODE=-601, SQLSTATE=42710, SQLERRMC=SCHEMANAME.TEST_TEMP;TABLE, DRIVER=4.14.122 and often even a very simple Message Error after running the same statement.
Running the query above (copy/paste) directly within a database SQL window doesn't return any errors.
How is it possible, in RobotFramework the query is executed successfully but nevertheless an error is thrown?
The error SQLCODE=-601 means that you are trying to create an object that already exists. So when you say that the table exists afterwards, it means that it existed before you ran the statement. I don't know the framework you are using, but the explanation by #pavelsaman in comment seems to be a very likely cause.
Postgres server is in hot standbuy mode.
Asynchronou streaming binary replication is used.
Command like
INSERT INTO logfile (logdate) values (current_date)
Causes error
cannot execute INSERT in a read-only transaction.
Maybe it should be changed to
INSERT INTO logfile (logdate)
SELECT current_date
WHERE ???
What where condition should used ?
It should work starting at Postgres 9.0
If direct where clause is not possible, maybe some plpgsql function can used in where.
Maybe
show transaction_read_only
result should captured or some function can used.
Alternately application can determine if database is read-only in startup. Should show transaction_read_only result used for this.
Running INSERT on a standby server is not possible in pure (non-procedural) SQL because when the server is in standby mode, all the data-modification queries are rejected in planning phase, before it's executed.
It's possible with conditionals in PL/PgSQL.
DO $code$
BEGIN
IF NOT pg_is_in_recovery() THEN
INSERT INTO logfile (logdate) VALUES (current_date);
END IF;
END;
$code$;
However, it's probably not recommended - it's usually better to test pg_is_in_recovery() once (in application code) and then act accordingly.
I'm using pg_is_in_recovery() system function instead of transaction_read_only GUC because it's not exactly the same thing. But if you prefer that, please use:
SELECT current_setting('transaction_read_only')::bool
More info: DO command, conditionals in PL/PgSQL, system information functions.
I was trying to see if there was a way to automatically set a user's VALID UNTIL value three months in the future without having to type out the literal date. Tried the following:
alter user rchung set valuntil = dateadd(day,90,GETDATE());
alter user rchung set valuntil = select dateadd(day,90,GETDATE());
both failed with a syntax error.
alter user rchung valid until dateadd(day,90,GETDATE());
also failed with a syntax error.
Anyone have any success with this?
TIA,
Rich
It appears that this is a limitation on the PostgreSQL side.
CREATE USER, like pretty much all utility statements in Postgres,
won't do any expression evaluation --- the parameters have to be
simple literal constants.
VALID UNTIL programmatically in SQL
Since Amazon Redshift doesn't support plpgsql like PostgreSQL, client side scripting is really the only option. If you're using a semi-modern version (9.3+) of psql the following works:
select dateadd(day,90,GETDATE()) as expiry; \gset
alter user myuser valid until :'expiry';
Does anyone know if DB2 v9.1 z/OS supports Table Valued User Defined Functions?
This is what I am trying to create but I keep getting the error message below.
CREATE FUNCTION func_test(v_vchCol CHAR(10))
RETURNS TABLE(col_a char(10), row_cnt integer)
LANGUAGE SQL
SPECIFIC FUNCINFO
NOT DETERMINISTIC
READS SQL DATA
return
select col_1, count(*)
from SCHEMA_NAME.TEST1
where col_1 = v_vchCol
group by col_1;
Error Message:
ERROR [56038] [IBM][DB2] SQL0969N There is no message text
corresponding to SQL error "-4700" in the message file on this
workstation. The error was returned from module "DSNHSMS1" with
original tokens "". SQLSTATE=56038
Any help would be much appreciated
Yes, but it appears to require new function mode which apparently isn't enabled yet in the DB2 instance you're connected to.