I've been trying to figure out the issue here. This is running in a bash script. And I am getting the error below. However, if I run the INSERT statement manually from within psql, it works fine.
psql -U zrec -d zrec -t -c "INSERT INTO approved_recommendations
SELECT * FROM dblink('conn_db_link','SELECT * FROM approved_recommendations') AS x(
ticker varchar,
status varchar,
approved_recommendation integer,
yesterday_recommendation integer,
prior_recommendation integer,
date_approved date,
approved_by integer,
date_suggested date,
suggested_by integer,
recommendation_date date,
flag_24hours integer,
display_processed character varying,
display_processed_date date);"
ERROR: could not establish connection
DETAIL: missing "=" after "conn_db_link" in connection info string
Any thoughts on what I am missing? Did I set up the DB Link wrong? It works manually.....
If you use SELECT dblink_connect('conn_db_link',...), you have to repeat it in each session. The setting does not survive. However, if you create a foreign server (like 'server_vegeta_remote' in the tutorial) then that does survive between sessions. You can use the name of the foreign server directly calls in dblink.
I don't see the point of SELECT dblink_connect('conn_db_link','server_vegeta_remote') in the tutorial. Why not just use 'server_vegeta_remote' directly, rather than creating temporary named connection based on it?
Related
I found at several places to be able to drop a schema in DB2 along with all of its contents (indexes, SPs, triggers, sequences etc) using
CALL SYSPROC.ADMIN_DROP_SCHEMA('schema_name', NULL, 'ERRORSCHEMA', 'ERRORTAB');
However, I am getting the following error while using this command:
1) [Code: -469, SQL State: 42886] The parameter mode OUT or INOUT is not valid for a parameter in the routine named "ADMIN_DROP_SCHEMA" with specific name "ADMIN_DROP_SCHEMA" (parameter number "3", name "ERRORTABSCHEMA").. SQLCODE=-469, SQLSTATE=42886, DRIVER=4.22.29
2) [Code: -727, SQL State: 56098] An error occurred during implicit system action type "2". Information returned for the error includes SQLCODE "-469", SQLSTATE "42886" and message tokens "ADMIN_DROP_SCHEMA|ADMIN_DROP_SCHEMA|3|ERRORTABSCHEMA".. SQLCODE=-727, SQLSTATE=56098, DRIVER=4.22.29
Can anyone help me suggest what's wrong here? I tried to look at several places but didn't get any idea. It doesn't seem it's an authorization issue. Using DB2 version 11.5.
You are using the ADMIN_DROP_SCHEMA procedure parameters incorrectly, assuming you are CALLing the procedure from SQL and not the CLP.
The third and fourth parameters cannot be a literal (despite the documentation giving such an example), instead they must be host-variables (because the the procedure requires them to be input/output parameters).
If the stored-procedure completes without errors it sets these parameters to NULL. so your code should check for this.
If the stored-procedure detects errors, it creates and adds rows to the specified table and leaves the values of these parameters unchanged, and you must then query that table to list the error(s). You should drop this table before calling the stored procedure otherwise the procedure will fail with -601.
Example:
--#SET TERMINATOR #
drop table errschema.errtable#
set serveroutput on#
begin
declare v_errschema varchar(20) default 'ERRSCHEMA';
declare v_errtab varchar(20) default 'ERRTABLE';
CALL SYSPROC.ADMIN_DROP_SCHEMA('SOMESCHEMA', NULL, v_errschema, v_errtab);
if v_errschema is null and v_errtab is null
then
call dbms_output.put_line('The admin_drop_schema reported success');
else
call dbms_output.put_line('admin_drop_schema failed and created/populated table '||rtrim(v_errschema)||'.'||rtrim(v_errtab) );
end if;
end#
You can use global variables if you would like to use ADMIN_DROP_SCHEMA outside of compound SQL
E.g.
CREATE OR REPLACE VARIABLE ERROR_SCHEMA VARCHAR(128) DEFAULT 'SYSTOOLS';
CREATE OR REPLACE VARIABLE ERROR_TAB VARCHAR(128) DEFAULT 'ADS_ERRORS';
DROP TABLE IF EXISTS SYSTOOLS.ADS_ERRORS;
CALL ADMIN_DROP_SCHEMA('MY_SCHEMA', NULL, ERROR_SCHEMA, ERROR_TAB);
I have about 6000 IPv6 addresses I need loaded into a postgres table. without even getting to the point of finding my 'if not exist error' it borks on the unescaped ':'
I don't know postgres that well, is there a LOAD DATA INFILE function that will read in the lines and ignore the ':' as well as look for existing records?
INSERT INTO ip_list (ip_addr)
SELECT 'ip_addr',
2600:3c01:e000:44:0:0:0:1,
2600:3c01:e000:44:0:0:0:2,
2600:3c01:e000:44:0:0:0:3,
2600:3c01:e000:44:0:0:0:4,
2600:3c01:e000:44:0:0:0:5,
2600:3c01:e000:44:0:0:0:7,
....
WHERE NOT EXIST(
SELECT 1 FROM ip_list WHERE name = 'ip_addr')
RETURNING id
);
ERROR: syntax error at or near ":"
LINE 3: 2600:3c01:e000:44:0:0:0:1,
Update:
This method never uploads any records:
You are now connected to database "postfix" as user "postgres".
postfix=# create temporary table t(ip_addr inet);
CREATE TABLE
postfix=# \copy t from '/var/www/localhost/htdocs/ipListScript'
postfix=# INSERT INTO ip_list(ip_addr)
select ip_addr from ip_list where
not exists (select 1 from ip_list where ip_list.ip_addr=ip_list.ip_addr);
Looks like you just need to put quotes around your IP addresses. Check out this pages for more info:
http://www.postgresql.org/docs/9.1/static/datatype-net-types.html
6000 addresses as constants in an SQL statement is unreasonable, besides your proposed syntax being incorrect anyway (a VALUES clause would be needed).
The reasonable way is to COPY into a temporary table from the file, and then insert from the temporary table to your final table, eliminating duplicates at the same time.
In psql:
create temporary table t(ip_addr inet);
\copy t from '/path/to/file.txt'
INSERT INTO ip_list(ip_addr)
select ip_addr from t where
not exists (select 1 from ip_list where ip_list.ip_addr=t.ip_addr);
The \copy is a command of the psql program that takes care of loading the file client-side and feeding it to the server.
If the context does not allow using the psql command, you may use the SQL statement COPY tablename FROM '/path/to/file.txt' but then you must be connected as superuser, and the file should be accessible on the server by the postgres user.
If these restrictions are not acceptable you want to use COPY tablename FROM STDIN and feed the data by your own means.
I get a weird error while trying to create a trigger in my Oracle 11g database using SQL Developer. Here is what I did:
My table:
CREATE TABLE COUNTRY_CODE(
ID NUMBER(19,0) PRIMARY KEY NOT NULL,
Code VARCHAR2(2) NOT NULL,
Description VARCHAR2(50),
created TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
created_by VARCHAR2(40) DEFAULT USER,
last_updated TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
last_updated_by VARCHAR2(40) DEFAULT USER,
archived CHAR(1) DEFAULT '0' NOT NULL );
The Sequence:
CREATE SEQUENCE COUNTRY_CODE_ID_SEQ START WITH 1 INCREMENT BY 1;
The trigger:
CREATE OR REPLACE TRIGGER COUNTRY_CODE_TRIGGER
BEFORE INSERT ON COUNTRY_CODE
FOR EACH ROW
DECLARE
max_id number;
cur_seq number;
BEGIN
IF :new.id IS NULL THEN
SELECT COUNTRY_CODE_ID_SEQ.nextval
INTO :new.id
FROM dual;
ELSE
SELECT GREATEST(NVL(MAX(id),0), :new.id)
INTO max_id
FROM COUNTRY_CODE;
SELECT COUNTRY_CODE_ID_SEQ.nextval
INTO cur_seq
FROM dual;
WHILE cur_seq < max_id
LOOP
SELECT COUNTRY_CODE_ID_SEQ.nextval
INTO cur_seq
FROM dual;
END LOOP;
END IF;
END;
Creating the table and the sequence works very well, but when I try to create my trigger, I get this error:
Error report:
ORA-00603: ORACLE server session terminated by fatal error
ORA-00600: internal error code, arguments: [kqlidchg0], [], [], [], [], [], [], [], [], [], [], []
ORA-00604: error occurred at recursive SQL level 1
ORA-00001: unique constraint (SYS.I_PLSCOPE_SIG_IDENTIFIER$) violated
00603. 00000 - "ORACLE server session terminated by fatal error"
*Cause: An ORACLE server session is in an unrecoverable state.
*Action: Login to ORACLE again so a new server session will be created
Does anyone know about this error?
Thanks
I finally found the answer to my problem:
Add this:
ALTER SESSION SET PLSCOPE_SETTINGS = 'IDENTIFIERS:NONE';
Or in Oracle SQL Developer:
Go to Tools | Preferences
Select Database | PL/SQL Compiler
Change the PLScope identifiers from All to None
Click on Ok
This fixes the issue...
There may be a solution for this here.
I have no other solution (and don't have the reputation to merely comment), but here is some information that might help get someone on the right track to solving this problem while still using PL/Scope.
I just had a similar issue, and looking into the PL/Scope feature helped me understand where the problem might come in. For my issue, I tried to create a trigger and the same exact error came up. I changed the body of the trigger to no avail, but changing the name worked fine.
It seems the the PL/Scope was holding onto information about the first instantiated trigger, before dropping it. A query on the triggers revealed my trigger was surely dropped, but a query on the (PL/Scope) identifiers ("all_identifiers") showed it was still there.
Some information on PL/Scope is here:
http://www.oracle.com/technetwork/testcontent/o67asktom-101004.html
Chapter 8 here (11g documentation) has more information:
http://docs.oracle.com/cd/B28359_01/appdev.111/b28424.pdf
I check below link which I used and running perfectly. But I want to opposite this things.
Postgresql: dblink in Stored Functions
My scenario: Two databases are there. I want to copy one table data from local to remote database. I used dblink for this used but I am confused how to use dblink to store the data?
Local database name: localdatabase
Remote Database name: remotedatabase
Can any one suggest me how can I do this?
Thanks in advance.
Something like the lines below should work:
SELECT dblink_connect('hostaddr=127.0.0.1 port=5432 dbname=mydb user=postgres password=mypasswd');
-- change the connection string to your taste
SELECT dblink_exec('INSERT INTO test (some_text) VALUES (''Text go here'');');
Where test is a table in the remote database with the following definition:
CREATE TABLE test(
id serial
, some_text text
);
After running dblink_exec(), you can check the results in the remote database (or locally, using dblink(), like in the example below).
SELECT * FROM dblink('SELECT id, some_text FROM test') AS d(id integer, some_text text);
id | some_text
----+--------------
1 | Text go here
(1 row)
You can wrap your dblink_exec call in a function as well:
CREATE OR REPLACE FUNCTION f_dblink_test_update(val text, id integer) RETURNS text AS
$body$
SELECT dblink_exec('UPDATE torles.test SET some_text=' || quote_literal($1) || ' WHERE id = ' || $2);
$body$
LANGUAGE sql;
As you can see, you can even build your query string dynamically. (Not that I advocate this approach, since you have to be careful not to introduce a SQL injection vulnerability into your system this way.)
Since dblink_exec returns with a text message about what it did, you have to define your function as RETURNS text unless there are other value-returning statements after the dblink_exec call.
I have been experiencing few problems with data encryption over pgcrypto with Postgresql 8.4.
First case : works fine :
select pgp_pub_decrypt(pgp_pub_encrypt('fsck',
dearmor(pubkey),'compress-algo=1,
cipher-algo=aes256'),dearmor(seckey)) from keytbl where keytbl.id=1
-> returns "fsck"
key 1 is pgp with no password
Second case : doesn't work
select pgp_pub_decrypt(pgp_pub_encrypt('fsck',
dearmor(pubkey),'compress-algo=1,
cipher-algo=aes256'),dearmor(seckey),'password') from keytbl where
keytbl.id=2
-> returns ERREUR: Corrupt data
When i generate keys with password pgcrypto doesn't want to decrypt the message crypted with the public key ....
Anyone got a guess ? This is driving me mad...
This appears to be a known bug in at least 8.4 and 9.0. I have avoided this in the past by avoiding using the passphrase functionality and using pgp_sym_encrypt and pgp_sym_decrypt to manage the keys' passphrases.
In general if this is giving you a problem your best option is to encrypt the keys with a passphrase separately using well-tested functions.
To give you an idea of how we do it:
create or replace function user__replace_keys
(in_public_key bytea, in_private_key bytea, in_passphrase text)
RETURNS user_key
LANGUAGE SQL AS
$$
UPDATE user_key
SET last_resort_key = pgp_pub_encrypt(
pgp_pub_decrypt(
last_resort_key,
pgp_sym_decrypt_bytea(priv_key, $3)
), $2
),
pub_key = $2,
priv_key = pgp_sym_encrypt_bytea($2, $3)
WHERE login = SESSION_USER
RETURNING *;
$$;
Note that the private key sent to the server must not be password encryted. We might actually generate it on the server or in middleware to avoid problems. This avoids bugs of the sort you are experiencing.