SQL> CREATE TABLE Product (id NUMBER(19,0) NOT NULL, name VARCHAR2(10 CHAR) NOT NULL);
Table created.
SQL> desc Product;
Name Null? Type
----------------------------------------- -------- ----------------------------
ID NOT NULL NUMBER(19)
NAME NOT NULL VARCHAR2(10 CHAR)
type NUMBER(19,0) becomes NUMBER(19).
From JDBC, the id type NUMBER(19) is mapped to java.sql.Types.DECIMAL, not java.sql.Types.BIGINT. What is the oracle database type mapped to jdbc BIGINT?
8.3.7 BIGINT
The JDBC type BIGINT represents a 64-bit signed integer value between
-9223372036854775808 and 9223372036854775807.
The corresponding SQL type BIGINT is a nonstandard extension to SQL.
In practice the SQL BIGINT type is not yet currently implemented by
any of the major databases, and we recommend that its use be avoided
in code that is intended to be portable.
The recommended Java mapping for the BIGINT type is as a Java long.
https://docs.oracle.com/javase/1.5.0/docs/guide/jdbc/getstart/mapping.html
However not entirely sure that statement about no RDBMS having implemented BIGINT that way, MS SQL Server documentation states:
Data type Range Storage
bigint -2^63 (-9,223,372,036,854,775,808) to 2^63-1 (9,223,372,036,854,775,807) 8 Bytes
https://learn.microsoft.com/en-us/sql/t-sql/data-types/int-bigint-smallint-and-tinyint-transact-sql
Notwithstanding the JDBC mapping is to LONG
Related
I am having the following script for H2 DB used in SpringBoot application tests:
create TABLE PARAMETER (
ID long auto_increment,
TYPE VARCHAR(100) not null,
VALUE VARCHAR(100) not null,
SORT_ORDER int not null
);
CREATE SEQUENCE PARAMETER_ID_SEQ MINVALUE 1 START WITH 1;
This script executes with previous H2 version <h2.version>1.4.196</h2.version>, but when updating to <h2.version>2.1.210</h2.version> the following error ocures and I cannot understand what the problem. Is there a new syntax with the upper version?
ERROR:
Reason: liquibase.exception.DatabaseException: Syntax error in SQL statement "create TABLE PARAMETER (\000a ID long [*]auto_increment,\000a TYPE VARCHAR(100) not null,\000a VALUE VARCHAR(100) not null,\000a SORT_ORDER int not null\000a);\000a\000aCREATE SEQUENCE PARAMETER_ID_SEQ MINVALUE 1 START WITH 1;"; expected "RAW, ARRAY, INVISIBLE, VISIBLE, NOT, NULL, AS, DEFAULT, GENERATED, ON, NOT, NULL, DEFAULT, NULL_TO_DEFAULT, SEQUENCE, SELECTIVITY, COMMENT, CONSTRAINT, COMMENT, PRIMARY, UNIQUE, NOT, NULL, CHECK, REFERENCES, ,, )"; SQL statement:
create TABLE PARAMETER (
ID long auto_increment,
TYPE VARCHAR(100) not null,
VALUE VARCHAR(100) not null,
SORT_ORDER int not null
);
CREATE SEQUENCE PARAMETER_ID_SEQ MINVALUE 1 START WITH 1; [42001-210] [Failed SQL: (42001) create TABLE PARAMETER (
ID long auto_increment,
TYPE VARCHAR(100) not null,
VALUE VARCHAR(100) not null,
SORT_ORDER int not null
);
CREATE SEQUENCE PARAMETER_ID_SEQ MINVALUE 1 START WITH 1;]
There is no such data type as long in SQL, where did you find it? You need to use BIGINT. H2 accepts long too, but it depends on compatibility mode, for example, it isn't allowed in PostgreSQL compatibility mode.
AUTO_INCREMENT should also be used only in MySQL and MariaDB compatibility modes, H2 also accepts it in REGULAR and LEGACY modes, but normally you need to use GENERATED BY DEFAULT AS IDENTITY.
VALUE is a keyword in H2 and it also a reserved word in the SQL Standard (even in archaic SQL-92). You cannot use it as an identifier without quotes, you need to write it as "VALUE" or "value" depending on case you want (quoted identifiers are case-sensitive by default). Actually there is a compatibility setting, you can add ;NON_KEYWORDS=VALUE to JDBC URL of H2, but it would be better to quote it in your scripts and application.
I wrote a pipelined function to query data from a remote database. I keep getting
ORA-06502: PL/SQL: numeric or value error: character string buffer too
small.
I think I do understand when this error would occur, for example when a table column is defined as VARCHAR2(10) and you try to insert something bigger than 10 byte. But in this case, I really don't see whats wrong.
Perhaps first I show the parameters of the local and the remote database. I think it might be important, that on both DBs NLS_LENGTH_SEMANTICS is set to BYTE.
Local DB (where the pipelined function is stored):
params local db
Remote DB (from where data is queried):
params remote db
Now the code in local db:
create or replace function f_get_pl_data return tb_pl_palette pipelined is
begin
for i in (select p.*, 123 LAGER from palette#myremotedb p)
loop
pipe row(tt_pl_palette(i.pid,i.bereich,i.regal,i.fach,i.ebene,i.vol_klasse,i.lhm_typ,i.zustand,i.neu_datum,
i.neu_zeit,i.neu_usr,i.aender_datum,i.aender_zeit,i.aender_usr,i.verl_datum,i.tournr,
i.fil_nr,i.retournr,i.fz_nr,i.fahrer_nr,i.eroeff_auswahl,i.tpa_knz,i.lfsaender_knz,
i.verladen_am,i.verladen_um,i.verladen_von,i.verladen_von2,i.leer_gew,i.soll_gew,
i.ist_gew,i.lager));
end loop;
return;
end;
CREATE OR REPLACE TYPE "TT_PL_PALETTE" AS OBJECT (
pid VARCHAR2(14),
bereich VARCHAR2(2),
regal VARCHAR2(2),
fach VARCHAR2(3),
ebene VARCHAR2(2),
vol_klasse INTEGER,
lhm_typ INTEGER,
zustand INTEGER,
neu_datum DATE,
neu_zeit VARCHAR2(11),
neu_usr VARCHAR2(4),
aender_datum DATE,
aender_zeit VARCHAR2(11),
aender_usr VARCHAR2(4),
verl_datum DATE,
tournr VARCHAR2(6),
fil_nr VARCHAR2(4),
retournr VARCHAR2(10),
fz_nr INTEGER,
fahrer_nr INTEGER,
eroeff_auswahl INTEGER,
tpa_knz VARCHAR2(1),
lfsaender_knz VARCHAR2(1),
verladen_am DATE,
verladen_um VARCHAR2(11),
verladen_von VARCHAR2(4),
verladen_von2 VARCHAR2(4),
leer_gew NUMBER(7,3),
soll_gew NUMBER(7,3),
ist_gew NUMBER(7,3),
lager NUMBER
)
CREATE OR REPLACE TYPE "TB_PL_PALETTE" as TABLE OF TT_PL_PALETTE
And this is the table specifications on remote db:
create table PALETTE
(
pid VARCHAR2(14) not null,
bereich VARCHAR2(2) not null,
regal VARCHAR2(2) not null,
fach VARCHAR2(3) not null,
ebene VARCHAR2(2) not null,
vol_klasse INTEGER,
lhm_typ INTEGER,
zustand INTEGER,
neu_datum DATE default trunc(sysdate),
neu_zeit VARCHAR2(11) default to_char(sysdate, 'HH24:MI:SS'),
neu_usr VARCHAR2(4),
aender_datum DATE,
aender_zeit VARCHAR2(11),
aender_usr VARCHAR2(4),
verl_datum DATE,
tournr VARCHAR2(6),
fil_nr VARCHAR2(4),
retournr VARCHAR2(10),
fz_nr INTEGER,
fahrer_nr INTEGER,
eroeff_auswahl INTEGER,
tpa_knz VARCHAR2(1) default '0',
lfsaender_knz VARCHAR2(1) default 'N',
verladen_am DATE,
verladen_um VARCHAR2(11),
verladen_von VARCHAR2(4),
verladen_von2 VARCHAR2(4),
leer_gew NUMBER(7,3),
soll_gew NUMBER(7,3),
ist_gew NUMBER(7,3)
)
So you can see, when I created the type in local db I choosed the exact sizes of the columns in remote db.
But when I execute/query the pipelined function, I get this error (sorry it's german, but I wrote english in title):
error message
How can this happen? Do you have any idea what's wrong?
Appreciate any help, thanks!
EDIT 2021-03-02:
#ShaunPeterson Thanks for reply, NLS_CHARACTERSET is set to AL32UTF8 on both DBs, local and remote.
I just found out, the problem seems to be caused by 2 different IDEs that are used in our company.
I am using PL/SQL Developer from allround automations. When I posted the table specifications on remote DB (table "PALETTE"), I connected to remote DB using that IDE, and it showed the column types/sizes as you can see in my original post. I repeat the first 6 columns:
create table PALETTE
(
pid VARCHAR2(14) not null,
bereich VARCHAR2(2) not null,
regal VARCHAR2(2) not null,
fach VARCHAR2(3) not null,
ebene VARCHAR2(2) not null,
vol_klasse INTEGER,
But when Oracle SQL Developer is used, then it looks like this:
CREATE TABLE "PSTEDI"."PALETTE"
( "PID" VARCHAR2(14 CHAR) NOT NULL ENABLE,
"BEREICH" VARCHAR2(2 CHAR) NOT NULL ENABLE,
"REGAL" VARCHAR2(2 CHAR) NOT NULL ENABLE,
"FACH" VARCHAR2(3 CHAR) NOT NULL ENABLE,
"EBENE" VARCHAR2(2 CHAR) NOT NULL ENABLE,
"VOL_KLASSE" NUMBER(*,0),
So it seems PL/SQL Developer just shows wrong specifications. I have no idea why it is like that, and I would like to know, but that's another question.
I solved my problem using the column types and sizes Oracle SQL Developer shows.
Thank you.
#Dietz, what you said was fine for me.
I'm having the same problem as you, I am wondering if it's a bug. Like you:
I created types in ADT exactly as in their respective table columns.
I set my NLS_LENGTH_SEMANTICS.
However:
I set a default in SQL Developer.
I am not accessing a remote DB.
I don't believe it's related to either of these.
FYI, I'm going to try one more thing and if it doesn't work, I'll open a ticket with Oracle Support. I will update here with what I find or workaround from Oracle Support.
I am facing an issue with my datastage job. I have to fill a table ttperiodeas in Oracle from a .csv file. The SQL query in Oracle connector is shown in this screenshot:
Oracle connector
And here is the oracle script
CREATE TABLE TTPERIODEAS
(
CDPARTITION VARCHAR2(5 BYTE) NOT NULL ENABLE,
CDCOMPAGNIE NUMBER(4,0) NOT NULL ENABLE,
CDAPPLI NUMBER(4,0) NOT NULL ENABLE,
NUCONTRA CHAR(15 BYTE) NOT NULL ENABLE,
DTDEBAS NUMBER(8,0) NOT NULL ENABLE,
DTFINAS NUMBER(8,0) NOT NULL ENABLE,
TAUXAS NUMBER(8,5) NOT NULL ENABLE,
CONSTRAINT PK_TTPERIODEAS
PRIMARY KEY (CDPARTITION, CDCOMPAGNIE, CDAPPLI, NUCONTRA, DTDEBAS)
)
PARTITION BY LIST(CDPARTITION)
(PARTITION P_PERIODEAS_13Q VALUES ('13Q'));
When running the job, I get the following message error and the table is not filled.:
The index 'USINODSD0.SYS_C00249007' its partition is unusable
Please I need help thanks
The index is global (i.e. not partitioned) because there is no using index local at the end of the definition. This is also true for the PK index shown above. (I'm assuming they are two different things, because by default the DDL above would create an index named PK_TTPERIODEAS, so I'm not sure what SYS_C00249007 is.) If you can drop and rebuild them as local indexes (i.e. partitioned to match the table) then truncating or dropping a partition will no longer invalidate indexes.
For example, you could rebuild the primary key as:
alter table ttperiodeas
drop primary key;
alter table ttperiodeas
add constraint pk_ttperiodeas primary key (cdpartition,cdcompagnie,cdappli,nucontra,dtdebas)
using index local;
I don't know how SYS_C00249007 is defined, but you could use something similar.
The create table command might be something like:
create table ttperiodeas
( cdpartition varchar2(5 byte) not null
, cdcompagnie number(4,0) not null
, cdappli number(4,0) not null
, nucontra varchar2(15 byte) not null
, dtdebas number(8,0) not null
, dtfinas number(8,0) not null
, tauxas number(8,5) not null
, constraint pk_ttperiodeas
primary key (cdpartition,cdcompagnie,cdappli,nucontra,dtdebas)
using index local
)
partition by list(cdpartition)
( partition p_periodeas_13q values ('13Q') );
Alternatively, you could add the update global indexes clause when dropping the partition:
alter table demo_temp drop partition p_periodeas_14q update global indexes;
(By the way, NUCONTRA should probably be a standard VARCHAR2 and not CHAR, which is intended for cross-platform compatibility and ANSI completeness, and in practice just wastes space and creates bugs.)
the message says that the index for the given partition is unusable: so you could try to rebuild the correponding index partition by the use of
create index [index_name] rebuild partition [partition_name]
(with the fitting values for [index_name] and [partition_nme].
Before you do that you should check the status of the index partitions in user_indexes - since your error message looks not like Oracle error messages usually do.
But since the index is global as William Robertson pointed out, this is not applicable for the given situation.
Here is the code I'm using in Oracle SQL Developer :
CREATE TABLE ORDER_ITEMS(
ITEM_NO NUMBER(10),
ITEM_DESCRIPTION VARCHAR(50),
SIZE VARCHAR(5),
COST NUMBER(8,2),
QUANTITY NUMBER(10),
TOTAL NUMBER(8,2),
ITEM_ORDER_NO NUMBER(10),
CONSTRAINT ITM_NO_PK PRIMARY KEY (ITEM_NO));
The error has to do with the SIZE and COST tables, if I change the names on those two tables (for example put an A at the end of them (SIZEA COSTA)) then the code works. Why are these table names invalid ?
I think you mean column where you're writing table. Also SIZE is a reserved word in Oracle SQL, as is NUMBER.
https://docs.oracle.com/cd/B19306_01/server.102/b14200/ap_keywd.htm
I'm trying to retrieve FK of a given table with JDBC metadata.
For that, I'm using the "getImportedKeys" function.
For my table 'cash_mgt_strategy', it give in resultset:
PKTABLE_CAT : 'HAWK'
PKTABLE_SCHEM : 'dbo'
PKTABLE_NAME : 'fx_execution_strategy_policy'
PKCOLUMN_NAME : 'fx_execution_strategy_policy_id'
FKTABLE_CAT : 'HAWK'
FKTABLE_SCHEM : 'dbo'
FKTABLE_NAME : 'cash_mgt_strategy'
FKCOLUMN_NAME : 'fx_est_execution_strategy_policy'
KEY_SEQ : '1'
UPDATE_RULE : '1'
DELETE_RULE : '1'
FK_NAME : 'fk_fx_est_execution_strategy_policy'
PK_NAME : 'cash_mgt_s_1283127861'
DEFERRABILITY : '7'
The problem is that the "FKCOLUMN_NAME : 'fx_est_execution_strategy_policy'" is not a real column of my table, but it seems to be truncated? (missing "_id" at the end)
When using an official Sybase sql client (Sybase Workspace), displaying the DDL of the table give for this constraint / foreign key:
ALTER TABLE dbo.cash_mgt_strategy ADD CONSTRAINT fk_fx_est_execution_strategy_policy FOREIGN KEY (fx_est_execution_strategy_policy_id)
REFERENCES HAWK.dbo.fx_execution_strategy_policy (fx_execution_strategy_policy_id)
So I'm wondering how to retrieve the full FKCOLUMN_NAME ?
Note that I'm using jconnect 6.0.
I've tested with jconnect 7.0, same problem.
Thanks
You haven't provided your ASE version so I'm going to assume the following:
dataserver was running ASE 12.x at some point (descriptor names limited to 30 characters)
dataserver was upgraded to ASE 15.x/16.x (descriptor names extended to 255 characters)
DBA failed to upgrade/update the sp_jdbc* procs after the upgrade to ASE 15.x/16.x (hence the old ASE 12.x version of the procs - descriptors limited to 30 characters - are still in use in the dataserver)
If the above is true then sp_version should show the older versions of the jdbc procs running in the dataserver.
The (obvious) solution would be to have the DBA load the latest version of the jdbc stored procs (typically found under ${SYBASE}/jConnect*/sp).
NOTE: Probably wouldn't hurt to have the DBA review the output from sp_version to see if there are any other upgrade scripts that need to be loaded (eg, installmodel, installsecurity, installcommit, etc).
Ok, so I've done some search on my DB server and I've found the code of stored proc sp_jdbc_importkey. In this code can see:
create table #jfkey_res(
PKTABLE_CAT varchar(32) null,
PKTABLE_SCHEM varchar(32) null,
PKTABLE_NAME varchar(257) null,
PKCOLUMN_NAME varchar(257) null,
FKTABLE_CAT varchar(32) null,
FKTABLE_SCHEM varchar(32) null,
FKTABLE_NAME varchar(257) null,
FKCOLUMN_NAME varchar(257) null,
KEY_SEQ smallint,
UPDATE_RULE smallint,
DELETE_RULE smallint,
FK_NAME varchar(257),
PK_NAME varchar(257) null)
create table #jpkeys(seq int, keys varchar(32) null)
create table #jfkeys(seq int, keys varchar(32) null)
The temporary tables #jpkeys and #jfkeys used to store the column names (for PK and FK) are typed with varchar(32) instead of 257!!
Need to search how to patch / update theses stored proc now.