In Oracle 19c, I want to specify the default value of a column and the collate property at the same time.
create table id_table(
name varchar2(64) collate binary_ai,
id varchar2(8) collate binary_ci
);
insert into id_table values('Christopher', 'ABCD1234');
SELECT collation(name), collation(id) from id_table;
COLLATION(NAME)
COLLATION(ID)
BINARY_AI
BINARY_CI
It was well specified as intended.
but,
create table id_table2(
name char default 'Y' collate binary_ai,
id varchar2(8)
);
insert into id_table2 values('c', 'ABCD1234');
SELECT collation(name), collation(id) from id_table2;
COLLATION(NAME)
COLLATION(ID)
USING_NLS_COMP
USING_NLS_COMP
If you specify the default value and collate together, an unintended value is specified.
The intent was to expect the same values as in the first example.
Are DEFAULT VALUE and COLLATE mutually exclusive?
Related
I need some help!
I have an API built in laravel 5.8, i am upgrading the platform to 6.2.
After all changes in configuration files and some scripts php, all my tests witch run the migrations on SQLite is broken.
The following error is displayed:
SQLSTATE[HY000]: General error: 1 no such collation sequence: utf8_general_ci (SQL: CREATE TABLE events (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, event VARCHAR(255) NOT NULL COLLATE BINARY, description CLOB DEFAULT NULL COLLATE BINARY, invitation CLOB DEFAULT NULL COLLATE BINARY, sale CLOB DEFAULT NULL COLLATE BINARY, information CLOB DEFAULT NULL COLLATE BINARY, city VARCHAR(255) NOT NULL COLLATE BINARY,
location VARCHAR(255) NOT NULL COLLATE BINARY, date_start DATE NOT NULL, time_start TIME NOT NULL, date_end DATE DEFAULT NULL, flyer CLOB DEFAULT NULL COLLATE BINARY, atv BOOLEAN DEFAULT '1', created_at DATETIME DEFAULT NULL, updated_at DATETIME DEFAULT NULL, location_map VARCHAR(255) DEFAULT NULL COLLATE utf8_general_ci --IFRAME com a localização do evento.
My intention is update to 7.x after resolve all issues on 6.2.
In the migrations, was enough to remove the collation option from the fields. Example:
Initially this way:
$table->string('field', 255)->charset('utf8')->collation('utf8_general_ci')->change();
The solution was as follows:
$table->string('field', 255)->charset('utf8')->change();
Removing this option will not force a collation not accepted by SQLite.
For Example ,
I have created a table ,
CREATE DATABASE es_db;
USE es_db;
DROP TABLE IF EXISTS es_table;
CREATE TABLE es_table (
id BIGINT(20) UNSIGNED NOT NULL,
PRIMARY KEY (id),
UNIQUE KEY unique_id (id),
client_name VARCHAR(32) NOT NULL,
modification_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
insertion_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);
Now assume i have to select those data which are greater than time i give as input .
consider this query for example,
SELECT *, UNIX_TIMESTAMP(modification_time) AS unix_ts_in_secs FROM es_table WHERE (UNIX_TIMESTAMP(modification_time) > :sql_last_modifiedvalue AND modification_time < NOW()) ORDER BY modification_time ASC
Is there away to translate the same to native query ? i can achieve the same with jdbctemplate but would like to know if this is possible with native query?
I defined an Oracle table this way:
CREATE TABLE MANUAL_CORRECTION
(
ID NUMBER(19,0) NOT NULL,
MODIFIED TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
MODIFIED_BY NUMBER(19,0) NOT NULL,
MODIFIED_PROPERTY VARCHAR2(20 BYTE) NOT NULL,
OLD_VALUE VARCHAR2(20 BYTE) NOT NULL,
NEW_VALUE VARCHAR2(20 BYTE) NOT NULL,
CONSTRAINT MODIFIED_BY_FK FOREIGN KEY (MODIFIED_BY) REFERENCES BENUTZER (ID) ENABLE,
PRIMARY KEY (ID)
);
I want to insert records via JPA which works well but the MODIFIED column stays always NULL although I specified that it should be set to the system timestamp by default.
How can I achieve that the system timestamp is set whenever a new entity/record is persisted?
Here is how I defined the column/entity property:
#Column(name = "MODIFIED", nullable = false, updatable = false, insertable = false, columnDefinition = "TIMESTAMP DEFAULT CURRENT_TIMESTAMP")
private Timestamp modified;
I think your JPA is sending explicitly NULL as the value for the column and The default value is applied only when you do not specify it in an insert column clause.
Insert into <table> (col1, col2) values (1, null) -- col2 - default value will not be applied
Insert into <table> (col1) values (1) -- col2 - default value will be applied
So if you want to apply default value even when NULL is explicitly passed as a value of the column, you can use the new feature of the Oracle 12c i.e. default on null
Refer this doc
Cheers!!
Here is my SQL (with explain):
EXPLAIN
UPDATE
VF_KRED kred
INNER JOIN GBI gbi ON
kred.vendor = gbi.vendor
INNER JOIN MASTER_DATA master_data ON
master_data.vendor_code = gbi.vendor
SET
kred.GBI_VAL_REP =
(CASE
WHEN kred.country = 'JP' THEN
CASE
WHEN gbi.WITHHOLD_TAX_CODE = 0 THEN 2
WHEN gbi.WITHHOLD_TAX_CODE = 'IN' THEN 1
END
ELSE
CASE
WHEN gbi.WITHHOLD_TAX_CODE = master_data.REDUCED_RATE THEN
CASE
WHEN gbi.WITHHOLD_TAX_CODE = 0 THEN 3
WHEN gbi.WITHHOLD_TAX_CODE BETWEEN 1 AND 19 THEN 4
END
ELSE 5
END
END);
Giving below the outcome:
Now, the UPDATE SQL takes ~6+ minutes.
Below are the indexes on tables:
VF_KRED table:
GBI table:
MASTER_DATA table:
VENDOR columns are all varchar(25) type.
-- EDIT: (describing whole table structure below):
SHOW CREATE TABLE GBI;
CREATE TABLE `GBI` (
`VENDOR` varchar(25) CHARACTER SET utf8 NOT NULL,
`COMPANY_CODE` varchar(5) CHARACTER SET latin1 NOT NULL DEFAULT '',
`VENDOR_NAME` varchar(100) CHARACTER SET utf8 NOT NULL DEFAULT '',
`WITHHOLD_TAX_TYPE` varchar(2) CHARACTER SET latin1 NOT NULL DEFAULT '',
`WITHHOLD_TAX_CODE` varchar(2) CHARACTER SET latin1 NOT NULL DEFAULT '',
`DOCUMENT_CURRENCY` varchar(4) CHARACTER SET latin1 NOT NULL DEFAULT '',
`CREATE_DT` datetime NOT NULL,
PRIMARY KEY (`VENDOR`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
SHOW CREATE TABLE VF_KRED;
CREATE TABLE `VF_KRED` (
`VENDOR` varchar(25) CHARACTER SET latin1 NOT NULL,
`COUNTRY_CODE` varchar(5) CHARACTER SET latin1 DEFAULT NULL,
`COUNTRY` varchar(3) CHARACTER SET latin1 DEFAULT NULL,
`SEARCH_TERM` varchar(100) CHARACTER SET latin1 DEFAULT NULL,
`CREATE_DT` datetime DEFAULT NULL,
`GBI_VAL_REP` int(11) NOT NULL DEFAULT 5,
PRIMARY KEY (`VENDOR`),
KEY `vf_kred` (`GBI_VAL_REP`),
KEY `VF_KRED_COUNTRY_IDX` (`COUNTRY`) USING BTREE,
CONSTRAINT `vf_kred_ibfk_1` FOREIGN KEY (`GBI_VAL_REP`) REFERENCES `VENDOR_RATE_CATEGORY` (`ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
SHOW CREATE TABLE MASTER_DATA;
CREATE TABLE `MASTER_DATA` (
`ID` int(11) NOT NULL AUTO_INCREMENT,
`VENDOR_CODE` varchar(25) CHARACTER SET latin1 DEFAULT NULL,
`VENDOR_NAME` varchar(2000) CHARACTER SET latin1 DEFAULT NULL,
`COUNTRY` varchar(2) CHARACTER SET latin1 DEFAULT NULL,
`APPLN_RECEIVED_FROM_US` datetime DEFAULT NULL,
`ITUNES_CONTRACT_NUM` varchar(2000) CHARACTER SET latin1 DEFAULT NULL,
`CONTRACT_EFFECTIVE_DT` datetime DEFAULT NULL,
`CONTRACT_EXPIRATION_DT` datetime DEFAULT NULL,
`AUTO_RENEWAL` varchar(10) CHARACTER SET latin1 DEFAULT NULL,
`REDUCED_RATE` int(11) DEFAULT NULL,
`FORM_17` varchar(45) CHARACTER SET latin1 DEFAULT NULL,
`RESIDENCY_CERT_ISSUE_DT` datetime DEFAULT NULL,
`TAX_AUTHORITY_SUBMISSION_DT` datetime DEFAULT NULL,
`TAX_AUTHORITY_ACCEPTANCE_DT` datetime DEFAULT NULL,
`STATUS` varchar(45) CHARACTER SET latin1 DEFAULT NULL,
`FORM_17_EXPIRATION` varchar(45) CHARACTER SET latin1 DEFAULT NULL,
`COMMENTS` varchar(2000) CHARACTER SET latin1 DEFAULT NULL,
`REMARKS` varchar(2000) CHARACTER SET latin1 DEFAULT NULL,
`CATEGORY` varchar(45) CHARACTER SET latin1 DEFAULT NULL,
PRIMARY KEY (`ID`),
KEY `MASTER_DATA_VENDOR_CODE_IDX` (`VENDOR_CODE`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=2369 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
Any clues?
Do not mix CHARACTER SETs (or datatypes or collations) on columns that need to be compared, as in a JOIN. Note how vendor is latin1 versus utf8. This slows down the JOIN. (Also, check vendor_code due to another join.)
The clue in EXPLAIN: "func". This implied that somehow vendor was being modified in order to perform the JOIN. The CREATE TABLE showed that the charset was different.
128MB for innodb_buffer_pool_size is find, even advisable, if you have only 1GB of RAM. For 8GB, 6G would be a better setting. By increasing the value, you will probably cut back on the I/O necessary to run this, and other, queries. Again, this impacts the speed of the JOIN.
I'm writing a report to get result from mysql database. The query has one parameter which is of type int in mysql database. I define a parameter of type java.lang.Integer but when I run the report and give it a value it doesn't return any data. I tried to change the parameter type to String, then I got incorrect results. Here is the report query:
SELECT
orders.`number` AS orders_number,
orders.`length` AS orders_length,
orders.`thick` AS orders_thick,
orders.`date` AS orders_date,
orders.`weight` AS orders_weight
FROM
`orders` orders
WHERE
orders.`customer_id` = $P{cust_id}
and here is the Order table schema:
CREATE TABLE `orders` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`customer_id` int(11) DEFAULT NULL,
`number` double DEFAULT NULL,
`length` double DEFAULT NULL,
`thick` int(11) DEFAULT NULL,
`weight` double DEFAULT NULL,
`date` date DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `customer_fk` (`customer_id`)
) ENGINE=InnoDB AUTO_INCREMENT=38 DEFAULT CHARSET=utf8$
Thanks,
Try switching the $P{} syntax for $P!{}. As in,
WHERE
orders.`customer_id` = $P!{cust_id}
Jasper usually works by converting the query to a java PreparedStatement object, then setting the parameters using the object's methods. The $P!{} syntax will do the parameter substitution before the query is converted to an object.