DB2/400 SQL : I'm working in a sql function witch is using a global temporary table. I've juste a problem to declare this table : SQL send me an error, but i don't see where is the problem ? Can someone telle me what 's about this error ?
Function with a declaring global temporary table
I don't speak or read french, but it appears that the error is telling you that your function definition expects a return value, but the function body does not return anything.
Now when creating a SQL scalar function, the function body starts out with declarations. These declarations are for variables and cursors. It is somewhat unfortunate that you create a global temporary table using a statement that starts with DECLARE. It doesn't belong in the declarations but in the procedure body.
.-NOT ATOMIC-.
>>-+--------+--BEGIN--+------------+---------------------------->
'-label:-' '-ATOMIC-----'
>--+---------------------------------------+-------------------->
| .-----------------------------------. |
| V | |
'---+-SQL-variable-declaration--+-- ; +-'
+-SQL-condition-declaration-+
+-return-codes-declaration--+
'-INCLUDE-statement---------'
>--+--------------------------------------+--------------------->
| .----------------------------------. |
| V | |
'---+-DECLARE CURSOR-statement-+-- ; +-'
'-INCLUDE-statement--------'
>--+---------------------------------+-------------------------->
| .-----------------------------. |
| V | |
'---+-handler-declaration-+-- ; +-'
'-INCLUDE-statement---'
.---------------------------------.
V |
>----+-----------------------------+-+--END--+-------+---------><
'-SQL-procedure-statement-- ; ' '-label-'
It is part of the SQL procedure statement!
The declaration section must come before the creation of any tables.
While it seems counter intuitive, DECLARE GLOBAL TEMPORARY TABLE is not a normal variable declaration.
Try moving the other variable declarations above the table declaration.
Related
Trying to pass a star (*) in a sql Hana place holder with an arrow notation
The following works OK:
Select * FROM "table_1"
( PLACEHOLDER."$$IP_ShipmentStartDate$$" => '2020-01-01',
PLACEHOLDER."$$IP_ShipmentEndDate$$" => '2030-01-01' )
In the following, when trying to pass a *, i get a syntax error:
Select * FROM "table1"
( PLACEHOLDER."$$IP_ShipmentStartDate$$" => '2020-01-01',
PLACEHOLDER.'$$IP_ItemTypecd$$' => '''*''',
PLACEHOLDER."$$IP_ShipmentEndDate$$" => '2030-01-01' )
The reason i am using the arrow notation, is since its the only way i know that allows passing parameters as in the example bellow: (as in linked post)
do begin
declare lv_param nvarchar(100);
select max('some_date')
into lv_param
from dummy /*your_table*/;
select * from "_SYS_BIC"."path.to.your.view/CV_TEST" (
PLACEHOLDER."$$P_DUMMY$$" => :lv_param
);
end;
There's a typo in your code. You need to use double quotes around parameter name, but you have a single quote. It should be: PLACEHOLDER."$$IP_ItemTypecd$$".
When you pass something to Calculation View's parameter, you already have a string, that will be treated as string and have quotes around it where they needed, so no need to add more. But if you really need to pass some quotes inside the placeholder's value you also need to escape them with backslash complementary to doubling them (it was found by doing data preview on calculation view and entering '*' as a value of input parameter, then you'll find valid SQL statement in the log of preview):
do
begin
select *
from "_SYS_BIC"."ztest/CV_TEST_PERF"(
PLACEHOLDER."$$P_DUMMY$$" => '''*'''
);
end;
/*
SAP DBTech JDBC: [339]: invalid number: : line 3 col 3 (at pos 13): invalid number:
not a valid number string '' at function __typecast__()
*/
/*And in trace there's no more information, but interesting part
is preparation step, not an execution
w SQLScriptExecuto se_eapi_proxy.cc(00145) : Error <exception 71000339:
not a valid number string '' at function __typecast__()
> in preparation of internal statement:
*/
do
begin
select *
from "_SYS_BIC"."ztest/CV_TEST_PERF"(
PLACEHOLDER."$$P_DUMMY$$" => '\'*\''
);
end;
/*
SAP DBTech JDBC: [257]: sql syntax error: incorrect syntax near "\": line 5 col 38 (at pos 121)
*/
But this is ok:
do
begin
select *
from "_SYS_BIC"."ztest/CV_TEST_PERF"(
PLACEHOLDER."$$P_DUMMY$$" => '\''*\'''
);
end;
LOG_ID | DATUM | INPUT_PARAM | CUR_DATE
--------------------------+----------+-------------+---------
8IPYSJ23JLVZATTQYYBUYMZ9V | 20201224 | '*' | 20201224
3APKAAC9OGGM2T78TO3WUUBYR | 20201224 | '*' | 20201224
F0QVK7BVUU5IQJRI2Q9QLY0WJ | 20201224 | '*' | 20201224
CW8ISV4YIAS8CEIY8SNMYMSYB | 20201224 | '*' | 20201224
What about the star itself:
As #LarsBr already said, in SQL you need to use LIKE '%pattern%' to search for strings contains parretn in the middle, % is equivalent for ABAP's * (but as far as I know * is more verbose placeholder in non-SQL world). So there's no out-of-the-box conversion of FIELD = '*' to FIELD like '%' or something similar.
But there's no LIKE predicate in Column Engine (in filter or in calculated column).
If you really need LIKE functionality in filter or calculated column, you can:
Switch execution engine to SQL
Or use match(arg, pattern) function of Column Engine, which now dissapeared from the pallete and is hidden quite well in the documentation (here, at the very end of the page, after digging into the description field of the last row in the table, you'll find the actual syntax for it. Damn!).
But here you'll meet another surprise: as long as Column Engine has different operators than SQL (it is more internal and more close to the DB core), it uses star (*) for wildcard character. So for match(string, pattern) you need to use a star again: match('pat string tern', 'pat*tern').
After all the above said: there are cases where you can really want to search for data with wildcards and pass them as parameter. But then you need to use match and pass the parameter as plain text without tricks on star (*) or something (if you want to use officially supported features, not trying to exploit some internals).
After adding this filter to RSPCLOGCHAIN projection node of my CV from the previous thread, it works this way:
do
begin
select *
from "_SYS_BIC"."ztest/CV_TEST_PERF"(
PLACEHOLDER."$$P_DUMMY$$" => 'CW*'
);
end;
LOG_ID | DATUM | INPUT_PARAM | CUR_DATE
--------------------------+----------+-------------+---------
CW8ISV4YIAS8CEIY8SNMYMSYB | 20201224 | CW* | 20201224
do
begin
select *
from "_SYS_BIC"."ztest/CV_TEST_PERF"(
PLACEHOLDER."$$P_DUMMY$$" => 'CW'
);
end;
/*
Fetched 0 row(s) in 0 ms 0 µs (server processing time: 0 ms 0 µs)
*/
The notation with triple quotation marks '''*''' is likely what yields the syntax error here.
Instead, use single quotation marks to provide the '*' string.
But that is just half of the challenge here.
In SQL, the placeholder search is done via LIKE and the placeholder character is %, not *.
To mimic the ABAP behaviour when using calculation views, the input parameters must be used in filter expressions in the calculation view. And these filter expressions have to check for whether the input parameter value is * or not. If it is * then the filter condition needs to be a LIKE, otherwise an = (equal) condition.
A final comment: the PLACEHOLDER-syntax really only works with calculation views and not with tables.
i just want to know if it is possible to declare variables on the DBeaver´s sql editor and use them on a query
You have to enable variable processing in the "SQL Processing" settings of DBeaver -> Window -> Preferences -> Database -> Editors -> SQL Editor -> SQL Processing. There is a block on Parameters with settings you can change. See the Dynamic Parameter binding section on the wiki.
You should then be able to do:
#set date = '2019-10-09'
SELECT ${date}::DATE, ${date}::TIMESTAMP WITHOUT TIME ZONE
which produces:
| date | timestamp |
|------------|---------------------|
| 2019-10-09 | 2019-10-09 00:00:00 |
Yes you can, using :.
An example:
SELECT * FROM "SYSIBM".SYSDUMMY1
WHERE IBMREQD = :YOUR_VARIABLE
Based on the incredibly helpful post from #nicoschl, here are a couple of minor improvements:
-- using declarations
#set datex_start = cast('2120-01-01' as date) as date_start;
-- datex_start is the var name
-- casting the value in the declaration saves us the work later
-- the var can be given a default fieldname (e.g. "date_start")
-- run as a standalone command since the subsequent SELECT statement doesn't return values when it's all run together
select
${datex_start}
;
This will return a value "2120-01-01" with a fieldname of "date_start".
In the DBeaver SQL editor you can type the following:
-- define variable
#set my_var='hello SQL world'
-- call variable
select :my_var
You can also use ${my_var} to reference the variable; $my_var however did not work for me. I am using DBeaver v. 21.1.
You have to enable at Dbeaver settings:
Top Window > Preferences > and then see print below (updated 2022/08).
I'd like to create a table name in Hive using variable substitution.
E.g.
SET market = "AUS";
create table ${hiveconf:market_cd}_active as ... ;
But it fails. Any idea how it can be achieved?
You should use backtrics (``) for name for that, like:
SET market=AUS;
CREATE TABLE `${hiveconf:market}_active` AS SELECT 1;
DESCRIBE `${hiveconf:market}_active`;
Example run script.sql from beeline:
$ beeline -u jdbc:hive2://localhost:10000/ -n hadoop -f script.sql
Connecting to jdbc:hive2://localhost:10000/
...
0: jdbc:hive2://localhost:10000/> SET market=AUS;
No rows affected (0.057 seconds)
0: jdbc:hive2://localhost:10000/> CREATE TABLE `${hiveconf:market}_active` AS SELECT 1;
...
INFO : Dag name: CREATE TABLE `AUS_active` AS SELECT 1(Stage-1)
...
INFO : OK
No rows affected (12.402 seconds)
0: jdbc:hive2://localhost:10000/> DESCRIBE `${hiveconf:market}_active`;
...
INFO : Executing command(queryId=hive_20190801194250_1a57e6ec-25e7-474d-b31d-24026f171089): DESCRIBE `AUS_active`
...
INFO : OK
+-----------+------------+----------+
| col_name | data_type | comment |
+-----------+------------+----------+
| _c0 | int | |
+-----------+------------+----------+
1 row selected (0.132 seconds)
0: jdbc:hive2://localhost:10000/> Closing: 0: jdbc:hive2://localhost:10000/
Markovitz's criticisms are correct, but do not produce a correct solution. In summary, you can use variable substitution for things like string comparisons, but NOT for things like naming variables and tables. If you know much about language compilers and parsers, you get a sense of why this would be true. You could construct such behavior in a language like Java, but SQL is just too crude.
Running that code produces an error, "cannot recognize input near '$' '{' 'hiveconf' in table name".(I am running Hortonworks, Hive 1.2.1000.2.5.3.0-37).
I spent a couple hours Googling and experimenting with different combinations of punctuation, different tools ranging from command line, Ambari, and DB Visualizer, etc., and I never found any way to construct a table name or a field name with a variable value. I think you're stuck with using variables in places where you need a string literal, like comparisons, but you cannot use them in place of reserved words or existing data structures, if that makes sense. By example:
--works
drop table if exists user_rgksp0.foo;
-- Does NOT work:
set MY_FILE_NAME=user_rgksp0.foo;
--drop table if exists ${hiveconf:MY_FILE_NAME};
-- Works
set REPORT_YEAR=2018;
select count(1) as stationary_event_count, day, zip_code, route_id from aaetl_dms_pub.dms_stationary_events_pub
where part_year = '${hiveconf:REPORT_YEAR}'
-- Does NOT Work:
set MY_VAR_NAME='zip_code'
select count(1) as stationary_event_count, day, '${hiveconf:MY_VAR_NAME}', route_id from aaetl_dms_pub.dms_stationary_events_pub
where part_year = 2018
The qualifies should be removed
You're using the wrong variable name
SET market=AUS; create table ${hiveconf:market}_active as select 1;
I am trying to INSERT data via a postgres function, and I can't quite get it working. I am getting an error stating
ERROR: function unnest(integer) does not exist
SQL state: 42883
Hint: No function matches the given name and argument types. You might need to add explicit type casts.
I am using Postgres 9.5, and my function is as follows:
CREATE FUNCTION insert_multiple_arrays(
some_infoid INTEGER[],
other_infoid INTEGER[],
some_user_info VARCHAR,
OUT new_user_id INTEGER
)
RETURNS INTERGER AS $$
BEGIN
INSERT INTO user_table (user_info) VALUES ($3) RETURNING user_id INTO new_user_id;
INSERT INTO some_info_mapper (user_id, some_info_id) SELECT new_user_id, unnest($1);
INSERT INTO other_info_mapper (user_id, other_info_id) SELECT new_user_id,unnest($2);
END;
$$ LANGUAGE plpgsql;
I will be calling the stored procedure from my backend via a SELECT statement. An example is like so:
createUser(user, callback){
let client = this.getDb();
client.query("SELECT insert_multiple_arrays($1, $2, $3)",
[user.some_info_ids, user.other_info_ids, user.info], function(err, results){
if(err){
callback (err);
}
callback(null, results);
});
};
The output that I am expecting would be as follows:
user_table
user_id | user_info |
----------------------+-----------------+
1 | someInfo |
some_info_mapper
user_id | some_info_id |
----------------------+-----------------+
1 | 33 |
1 | 5 |
other_info_mapper
user_id | other_info_id |
----------------------+-----------------+
1 | 8 |
1 | 9 |
1 | 22 |
1 | 66 |
1 | 99 |
How do I handle this error? Do I need to do some sort of processing to my data to put it into a format that postgres accepts?
You're calling insert_multiple_arrays with three parameters, but show the definition with four. Perhaps you have an old 3-parameter version still lurking there, buggy, and trying to find the bug in the 4-parameter version that is not actually in use?
After exploring #cachiques comments, it appears that the data was not being sent correctly after all. As it turns out, that the data being passed to the back end was an array objects that needed to be parsed further than I realized. Once parsed, the sql worked fine. Here is the code I used to parse from the server side, which would be sent to the sql query:
user.other_info_ids = req.body.other_info.map( function(obj) { return obj.info_id; } );
I am looking for few global variable in mysql which are equivalent of sql server.
I want the whole list
eg.
Sql Server Equivalent
##error ---
##Identity ---
etc.
Basically right now I want to know what are the equivalent variable of ##error and ##identity.
But it will be helpfull if u could provide some other variable also
The last auto_increment value (i.e. the last identity) generated for the current connection can be found using the LAST_INSERT_ID() function.
About errors, not sure ; there doesn't seem to be any system variable that corresponds to the last error message.
There is a show errors statement :
mysql> select a from b;
ERROR 1046 (3D000): No database selected
mysql> show errors;
+-------+------+----------------------+
| Level | Code | Message |
+-------+------+----------------------+
| Error | 1046 | No database selected |
+-------+------+----------------------+
1 row in set (0,00 sec)
But not sure how you can use this result...
After searching a bit more, I found out this thread : Getting the last error message, which says (quoting) :
I think there should be something like
##last_error_id and
##last_error_message, but I can`t
find anything in the current manual.
And the first answer states (quoting) :
This isn't possible currently, from
what we understand error handling will
be improved in version 5.2 and
hopefully something like this may be
possible.
If you are interested in the number of errors (or if there was an error), using ##error_count seems to work.
> select a from bogus_table;
(1054, "Unknown column 'a' in 'field list'")
> select ##error_count;
+---------------+
| ##error_count |
+---------------+
| 1 |
+---------------+
Regarding Errors, there is a facility using which you can get the error number and other things. There is a utility named GET DIAGNOSTICS using which you can query database diagnostics data. Refer the example below -
GET DIAGNOSTICS #NUM = NUMBER, #rowsAffected = ROW_COUNT;
-- here #NUM and #rowsAffected are user variables. Any other variables can work here as well.
In above statement you can get number of error conditions and number of rows affected. For error conditions we refer another variant of this utility which consumes number of error count that we got from above statement.
GET DIAGNOSTICS CONDITION #NUM
#errNo = mysql_errno, -- Error Number
#msg = message_text, -- Error Message Text
#sqlState = sqlstate_returned -- Affected SQL State under which error occured
;
A word of caution though - use these statement as soon as you expect your sql to fail. Since these capture internals database diagnostics any other function can quickly overlap your session data.
For more on this, refer link here