Can a varchar datatype consist numeric values and special characters in it?
If yes, please elaborate.
There's nothing much I'd like to elaborate. Documentation (11g version; pick any other you might be using) explains mostly everything:
The VARCHAR2 datatype stores variable-length character strings.
Example:
SQL> create table test (col varchar2(20));
Table created.
SQL> -- string
SQL> insert into test values ('abc');
1 row created.
SQL> -- number - implicitly converted to varchar2 datatype
SQL> insert into test values (100);
1 row created.
SQL> -- special characters - not exactly "special", as they are enclosed into
SQL> -- single quotes so they are actually treated as "strings", but yes - you
SQL> -- can store them into a varchar2 column as well
SQL> insert into test values ('#$%');
1 row created.
SQL> select * from test;
COL
--------------------
abc
100
#$%
SQL>
It is an indeterminate length string data type. It can hold numbers, letters and special characters.For varchar you need to check ASCII and EXTENDED ASCII character as these are allowed in a char/varchar field.
Related
I have been trying to use different functions on clob datatype in oracle 19.3.0.0 and none of them return values.
eg : -
dbms_lob.getlength(clob_data)
However any kind of functions on clob/blob datatype doesn't return values
length(clob_data)
These functions have been working fine previously in Oracle 12c. I recently upgraded to Oracle 19.3.0.0. Please educate me if there is any work around for this.
If you don't want to insert anything in clob column you should use empty_clob function
Test case
SQL> create table test1 (id number,a clob);
Table created.
SQL> insert into test1 values (&id,&a);
Enter value for id: 1
Enter value for a: null
1 row created.
SQL> /
Enter value for id: 2
Enter value for a: empty_clob()
1 row created.
SQL> commit;
Commit complete.
SQL> select id,dbms_lob.getlength(a) length from test1;
ID LENGTH
---------- ----------
1
2 0
I'm retrieving data from an oracle database using sqlplus.
The command is something like this:
select property_name||'|'||property_value from some_table where x = 'foo'
and the data in the database definitely has trailing spaces (this is a thing which causes problems in an application I work with).
When I retrieve that data the spaces have been automatically trimmed somehow. I can see them when I use SQLDeveloper and when retrieved by the application directly.
Is there a way I can stop this happening?
Here is how it should be working.
SQL> create table spaces (blanks varchar2(20));
Table created.
SQL> insert into spaces values ('A');
1 row created.
SQL> insert into spaces values ('A ');
1 row created.
SQL> insert into spaces values ('A ');
1 row created.
SQL> Insert into SPACES (BLANKS) values ('A
B ');
SQL> commit;
Commit complete.
SQL> select blanks, length(blanks), blanks || '!' from spaces;
BLANKS LENGTH(BLANKS) BLANKS||'!'
-------------------- -------------- ---------------------
A 1 A!
A 6 A !
A 3 A !
A 9 A
B B !
SQL>
The last column shows that none of the 'blanks' are being trimmed. Can you share your scenario in your question details? Or try what I've demonstrated and compare.
If I execute the following script in SQLPlus:
CREATE TABLE trailing_spaces (text VARCHAR2(100))
/
-- Note that there is a blank space after 'one' and 'two'
INSERT INTO trailing_spaces (text) VALUES ('one
two
three')
/
COMMIT
/
SQLPlus automatically trims the lines and removes the trailing spaces, so that instead of inserting the value one two three is inserting onetwothree.
Does anyone know how to keep SQLPlus from trimming those lines and execute the script as it is?
You can do it as in SQLPLUS :
SQL> CREATE TABLE trailing_spaces (text VARCHAR2(100));
Table created.
SQL> INSERT INTO trailing_spaces (text) VALUES ('one'||' '||
'two'||' '||
'three') ;
1 row created.
SQL> COMMIT;
Commit complete.
SQL> SELECT * FROM TRAILING_SPACES;
TEXT
--------------------------------------------------------------------------------
one two three
If I execute your insert statement, I get the text on three different lines. How could you get the text in one line as onetwothree? I am using Oracle 11.2.0.4
In my case, if I cannot alter the script, I can run the existing script and manipulate it during the selection as shown below.
SQL> insert into tbl1 values('one
2 two');
1 row created.
SQL> insert into tbl1 values('three
2 four');
1 row created.
SQL> select * from tbl1;
TEXT
--------------------
one
two
three
four
SQL> select REPLACE(REPLACE(text, CHR(10)), CHR(13)) as text from tbl1;
TEXT
--------------------
one two
three four
I have a PL/SQL script which executes a number of procedures on an oracle DB.
The script defines:
DECLARE
productkey VARCHAR2(100);
BEGIN
productKey := '000000000070307037';
...
ProcedureName(productKey);
The procedure expects a VARCHAR2
PROCEDURE ProcedureName (
productKey VARCHAR2
)
The procedure inserts into a table:
BEGIN
Insert into Mytable
(
THIS_PRODUCT_KEY
)
Values
(productKey);
When I query that table, the product Key = 70307037, ie the leading 0's have been lost.
I saw some similar questions where TO_CHAR was suggested, I tried defining productKey in the script using TO_CHAR, and also modifiying the procedure to write using TO_CHAR:
BEGIN
Insert into Mytable
(
THIS_PRODUCT_KEY
)
Values
(TO_CHAR(productKey,'000000000000000000'));
Still coming through without the leading 0's.
There are multiple queries that join using the product key and don't work when the 0's are missing.
Why would I lose the 0's when the variable is a VARCHAR ?
I believe that "THIS_PRODUCT_KEY" column in your "Mytable" table is not a varchar2 column. I think it is number. If you change the datatype of the "THIS_PRODUCT_KEY" column to varchar2, it won't lose the 0s.
i have the following function:
create or replace
FUNCTION "MXUPGKEYVAL"(tbname varchar2,colname varchar2) return number is
val number;
BEGIN
EXECUTE IMMEDIATE
'select sum(length('||colname||')) from '||tbname into val;
return val;
END;
and the following update:
update ANINTEGDATA set val1=to_char(nvl(MXUPGKEYVAL(MX5T,MX5C),0)) where type=1;
when i execute the update i get:
ORA-00932: inconsistent datatypes: expected NUMBER got LONG
ORA-06512: at "MAXIMO.MXUPGKEYVAL", line 6
ORA-06512: at line 2
any idea why that happens?
Regards,
Radu.
Later edit:
table ANINTEGDATA is:
create table ANINTEGDATA
(
MX5T VARCHAR2(50),
MX5C VARCHAR2(50),
MX6T VARCHAR2(50),
MX6C VARCHAR2(50),
TYPE NUMBER,
VAL1 VARCHAR2(200),
VAL2 VARCHAR2(200)
);
Your function works.
SQL> select mxupgkeyval('EMP', 'SAL') from dual
2 /
MXUPGKEYVAL('EMP','SAL')
------------------------
78
SQL>
Furthermore it works in your update statement.
SQL> update ANINTEGDATA set val1=to_char(nvl(MXUPGKEYVAL(MX5T,MX5C),0)) where type=1;
1 row updated.
SQL>
Where it doesn't work is when the column in question has the LONG datatype. The error message isn't as clear as it could be but is clear enough.
SQL> alter table t34 add long_col long;
Table altered.
SQL> select mxupgkeyval('T34', 'LONG_COL') from dual
2 /
select mxupgkeyval('T34', 'LONG_COL') from dual
*
ERROR at line 1:
ORA-00932: inconsistent datatypes: expected NUMBER got LONG
ORA-06512: at "APC.MXUPGKEYVAL", line 6
SQL>
This is just another reason why LONG is Teh Suck! and should have been done away with a long time ago. As you're doing a data migration exercise now would be a good time to consider moving to the oh-so flexible CLOB data type.
Either way you need a convention to indicate that the target column contains a shedload of data.
If you really need to know the precise extent of the LONG data volumes I suggest you unload the LONGs to CLOB columns and sum those instead.