I'm a newbie in Ingres and OpenRoad. Is it possible to have a database stored procedure return two values?
I want to return an integer and a varchar to use in multiple OpenRoad frames.
I can create the stored procedure but the parameter does not return the varchar value. I'm using the return value as my integer variable.
I used out parameters to solve this
Related
I have a BLOB field in a table that I am selecting. This field data consists only of JSON data.
If I do the following:
Select CAST(JSONBLOB as VARCHAR(2000)) from MyTable
--> this returns the value in VARCHAR FOR BIT DATA format.
I just want it as a standard string or varcher - not in bit format.
That is because I need to use JSON2BSON function to convert the JSON to BSON. JSON2BSON accepts a string but it will not accept a VarChar for BIT DATA type...
This conversation should be easy.
I am able to do the select as a VARCHAR FOR BIT DATA.. Manually COPY it using the UI. Paste it into a select literal and convert that to BSON. I need to migrate a bunch of data in this BLOB from JSON to BSON, and doing it manually won't be fast. I just want to explain how simple of a use case this should be.
What is the select command to essentially get this to work:
Select JSON2BSON(CAST(JSONBLOB as VARCHAR(2000))) from MyTable
--> Currently this fails because the CAST converts this (even though its only text characters) to VARCHAR for BIT DATA type and not standard VARCHAR.
What is the suggestion to fix this?
DB2 11 on Windows.
If the data is JSON, then the table column should be CLOB in the first place...
Having the table column a BLOB might make sense if the data is actually already BSON.
You could change the blob into a clob using the converttoclob procedure then you should be ok.
https://www.ibm.com/support/knowledgecenter/SSEPGG_11.5.0/com.ibm.db2.luw.apdv.sqlpl.doc/doc/r0055119.html
You can use this function to remove the "FOR BIT DATA" flag on a column
CREATE OR REPLACE FUNCTION DB_BINARY_TO_CHARACTER(A VARCHAR(32672 OCTETS) FOR BIT DATA)
RETURNS VARCHAR(32672 OCTETS)
NO EXTERNAL ACTION
DETERMINISTIC
BEGIN ATOMIC
RETURN A;
END
or if you are on Db2 11.5 the function SYSIBMADM.UTL_RAW.CAST_TO_VARCHAR2 will also work
I want to write a stored procedure in PostgreSQL that get input parameters and then select data based on conditions using that input parameter values. How I can achieve this easily?
I only have to use the PostgreSQL stored procedure and and not function for this
In PostgreSQL if we want to return result set in tabular format we have to use functions. they are best way designed to do this all functionality
In below code i have created sample table and written store procedure for exception handling ,the problem is if i insert integer values into columns name and email it is executing .if i pass integer values for name and email columns it should throw exception saying that your passing data types is wrong for name and email columns.
Can any one help me.
CREATE TABLE people
(
id integer NOT NULL,
name text,
email text,
CONSTRAINT people_pkey PRIMARY KEY (id)
)
CREATE OR REPLACE FUNCTION test() RETURNS integer AS'
BEGIN
BEGIN
INSERT INTO people(id,name,email) values(1,5,6);
EXCEPTION
WHEN OTHERS THEN RETURN -1;
END;
RETURN 1;
END'LANGUAGE plpgsql;
select * from test()
select * from people
This is the normal behavior, and it's not related to exception or error handling.
Assigning a numeric value to a text field in an SQL query works seamlessly, because PostgreSQL applies an implicit cast to the numeric literal (this also works with just about any datatype, since they all have a text representation through their I/O conversion routine).
This is tangentially mentioned in the doc for CREATE CAST:
It is normally not necessary to create casts between user-defined
types and the standard string types (text, varchar, and char(n), as
well as user-defined types that are defined to be in the string
category). PostgreSQL provides automatic I/O conversion casts for
that. The automatic casts to string types are treated as assignment
casts, while the automatic casts from string types are explicit-only.
What attribute of column I should use in order to get index value from postgresql sequence? valueNumeric? valueComputed?
As far as I understand the value of attribute should be nextval( 'simple_id_seq' ).
In postgresql sequence values are created as INTEGER or BIGINT.
Often this was done by using SERIAL or BIGSERIAL as column type ... but will indirectly create a sequencer of int or bigint and set the default value of the column to nextval(sequencer).
In a resultset of table data the column contains int or bigint.
Normaly there is no need to use nextval(sequencer) ... it fills the column on INSERT automatically (in the INSERT statemant the column shoult not appear).
Refer to http://www.postgresql.org/docs/9.3/static/datatype-numeric.html
If you do not want to use SERIAL or BIGSERIAL as suggested by #double_word_distruptor, use valueComputed.
With valueComputed you are telling Liquibase you are passing a function like nextval('simple_id_seq') and it will not try to parse it as a number or do any quoting.
You may also be able to use valueSequenceNext="simple_id_seq" to gain a little cross-database compatibility.
Declare #tempTableVariable Table(
email varchar(50)
)
Insert INTO #tempTableVariable
EXEC GetData
select email
from #tempTableVariable
I get the following error:
"Column name or number of supplied values does not match table definition."
Is there a simple way of getting a subset from GetData without explicitly declaring all the fields in the table variable declaration?
If you don't have control over the GetData stored procedure, I don't think there is any way you can get around having to declare all the fields in your table variable.
If you can control GetData, you could add a parameter to it that when equal to 1 would returnt the results the way you want them, and otherwise would do what it does currently.
I'll mention it for the sake of completeness, but there are lots of other options besides INSERT EXEC. http://www.sommarskog.se/share_data.html is a great explanation of the options.