The documentation you are referring to describes a manual setup using either an Oracle wallet or a certificate.
My question is regarding native encryption. When using either Oracle SQL*net or Oracle JDBC driver I only have to set two parameters in SQLNet.ora or JDBC configuration:
* SQLNET.ENCRYPTION_SERVER =ACCEPTED
* SQLNET.ENCRYPTION_TYPES_SERVER = AES256
I don't have to bother with wallets or certificates, everything is managed automatically by Oracle.
Our customers are asking if this can be used together with direct TCP/IP.
Search found 8 matches
- Thu 23 Sep 2021 07:10
- Forum: Oracle Data Access Components
- Topic: Using SQL*Net Native Encryption with Direct TCP/IP
- Replies: 7
- Views: 24717
- Wed 22 Sep 2021 08:43
- Forum: Oracle Data Access Components
- Topic: Using SQL*Net Native Encryption with Direct TCP/IP
- Replies: 7
- Views: 24717
Using SQL*Net Native Encryption with Direct TCP/IP
Our customer wants to introduce SQL*Net native encryption by setting SQLNET.ORA server parameters
* SQLNET.ENCRYPTION_SERVER =ACCEPTED
* SQLNET.ENCRYPTION_TYPES_SERVER = AES256
How can we use this with ODAC and a direct TCP/IP connection?
* SQLNET.ENCRYPTION_SERVER =ACCEPTED
* SQLNET.ENCRYPTION_TYPES_SERVER = AES256
How can we use this with ODAC and a direct TCP/IP connection?
- Thu 30 Apr 2020 11:03
- Forum: Oracle Data Access Components
- Topic: OraScript cannot parse PL/SQL block preceeded by a comment
- Replies: 1
- Views: 1924
OraScript cannot parse PL/SQL block preceeded by a comment
The latest ODAC build introduced a problem with the TOraScript component.
if your script contains an anonymous PL/SQL block that is preceeded by a comment, the OraScript component takes the first two lines as a separate statement, i.e. the line starting with "begin" is handled as the beginning of the next statement.
You can reproduce it using the following example:
Regards,
Holger
if your script contains an anonymous PL/SQL block that is preceeded by a comment, the OraScript component takes the first two lines as a separate statement, i.e. the line starting with "begin" is handled as the beginning of the next statement.
You can reproduce it using the following example:
Code: Select all
-- this is a comment
declare
i integer;
begin
null;
end;
Holger
- Wed 13 Dec 2017 08:45
- Forum: Oracle Data Access Components
- Topic: Delphi XE10.2.2 Update
- Replies: 4
- Views: 2493
Delphi XE10.2.2 Update
I installed Delphi XE 10.2 Tokyo Update 2 and now I get an error
Unit MemDS was compiled with a different version of System.Generics.Collections.TArray.Sort
Can you please upload a new compiled version?
Unit MemDS was compiled with a different version of System.Generics.Collections.TArray.Sort
Can you please upload a new compiled version?
- Tue 12 Dec 2017 11:04
- Forum: Oracle Data Access Components
- Topic: OCI-22060: argument [2] is an invalid or uninatialized number
- Replies: 2
- Views: 4019
OCI-22060: argument [2] is an invalid or uninatialized number
Please ceate a teable like that
Now create a Delphi form to edit the table using
* TOraSession: SQL*Net connection; Options.EnableLargeInt := True; Options.EnableNumbers := True
* TSmartQuery: DmlRefresh := True; Options.ReturnParams := True
* TOraDatasource
* Data grid
When editing data, you will get the error mentioned in the subject.
Environment:
* Oracle DB 11.2.0.2.0
* Oracle Client 12.1.0.0.0
* Windows 7
Code: Select all
CREATE TABLE ATEST
( ID NUMBER (9,0) NOT NULL,
ID12 NUMBER (12,0),
ID16 NUMBER (16,0),
ID20 NUMBER (20,0),
ID28 NUMBER (28,0),
IDNUM NUMBER,
DM DATE)
/
ALTER TABLE ATEST ADD
( CONSTRAINT ATEST_PK PRIMARY KEY(ID) )
/
CREATE OR REPLACE TRIGGER ATEST_BIUR
BEFORE INSERT OR UPDATE
ON ATEST
REFERENCING OLD AS OLD NEW AS NEW
FOR EACH ROW
BEGIN
:new.DM := SYSDATE;
END;
/
INSERT INTO ATEST( ID, ID12, ID16, ID20) VALUES( 123456789, 123456789012, 1234567890123456, 1234567890123467894));
COMMIT;
* TOraSession: SQL*Net connection; Options.EnableLargeInt := True; Options.EnableNumbers := True
* TSmartQuery: DmlRefresh := True; Options.ReturnParams := True
* TOraDatasource
* Data grid
When editing data, you will get the error mentioned in the subject.
Environment:
* Oracle DB 11.2.0.2.0
* Oracle Client 12.1.0.0.0
* Windows 7
- Mon 20 Nov 2017 12:45
- Forum: Oracle Data Access Components
- Topic: Is there a region support for timestamp columns?
- Replies: 4
- Views: 2781
Re: Is there a region support for timestamp columns?
Are there any news regarding this issue?
- Wed 04 Oct 2017 06:36
- Forum: Oracle Data Access Components
- Topic: Is there a region support for timestamp columns?
- Replies: 4
- Views: 2781
Re: Is there a region support for timestamp columns?
Server:
Problem does only occur in 64 Bit, 32 Bit is OK.
I tried it again with 11.2.0.1.0 (x64) client and it works OK.
So it looks like it is related to a problem with Oracle 12 client and 11.2 database.
- Oracle 11.2.0.3.0 Enterprise Edition
AMERICAN, AMERICA, WE8MSWIN1252
- Windows 7
12.1.0.0.0 Production
AMERICAN_AMERICA.WE8MSWIN1252
Problem does only occur in 64 Bit, 32 Bit is OK.
I tried it again with 11.2.0.1.0 (x64) client and it works OK.
So it looks like it is related to a problem with Oracle 12 client and 11.2 database.
- Thu 28 Sep 2017 12:15
- Forum: Oracle Data Access Components
- Topic: Is there a region support for timestamp columns?
- Replies: 4
- Views: 2781
Is there a region support for timestamp columns?
Lets execute the following statments to create a test case
If we query the data using
it gives a result like this
Now we create a Delphi application that contains a TOraSession, TSmartQuery and a grid component.
After connect, we execute
Then we open the TSmartquery, and change the hour of the timestamp.
Now we query again
it gives a result like this
That means, the region information has been lost.
Problem 2:
If we use a TIMESTAMP with local timezone column, and update to dates in January and in July, it should automatically apply a +01:00 for winter time and +02:00 for summer time.
It works fine, when you are using SQL. When you are changing the data in the grid, there is no difference between summer and winter time.
Problem 3:
In 64 bit mode, when connected to an Oracle 11g2 database, we often get an ORA-01805 "possible error in date/time operation", when trying to change data using a data grid. (Text edit, no date/time picker)
Code: Select all
ALTER SESSION SET TIME_ZONE='Europe/Berlin';
CREATE TABLE TEST_TIME (
ID NUMBER (28,0) NOT NULL,
TSZ TIMESTAMP(6) WITH TIME ZONE,
CONSTRAINT TEST_TIME_PK PRIMARY KEY (ID ));
INSERT INTO TEST_TIME ( ID, TSZ) VALUES ( 1, sysdate);
/
Code: Select all
select TSZ, TO_CHAR(TSZ, 'TZR') TSZ_ZONE from TEST_TIME where ID = 1
Code: Select all
28.09.2017 13:43:11,000000 +02:00 EUROPE/BERLIN
After connect, we execute
Code: Select all
ALTER SESSION SET TIME_ZONE='Europe/Berlin';
Now we query again
Code: Select all
select TSZ, TO_CHAR(TSZ, 'TZR') TSZ_ZONE from TEST_TIME where ID = 1
Code: Select all
28.09.2017 13:43:11,000000 +02:00 +02:00
Problem 2:
If we use a TIMESTAMP with local timezone column, and update to dates in January and in July, it should automatically apply a +01:00 for winter time and +02:00 for summer time.
It works fine, when you are using SQL. When you are changing the data in the grid, there is no difference between summer and winter time.
Problem 3:
In 64 bit mode, when connected to an Oracle 11g2 database, we often get an ORA-01805 "possible error in date/time operation", when trying to change data using a data grid. (Text edit, no date/time picker)