Timestamp column when reversed in ODI ,Logical Length increases to 11

Hi
I have a Timestamp Column in Oracle Database. When i see in SQL Developer
I see DataType: Timestamp(6),But when I reverse in ODI the Logical length Increases
to 11 and this gives an error when I execute my interface.
Like that I have Many timestamp column in my project and for the Interface to work
I have to manually decrease the length from 11 to 6,then it works fine.
Is there any workaround.
Thanks in Advance.

Hi,
Trying to help you. :-)
Try to use Datatypes options in ODI. Go to Topology mgr->Physical Arch, elapse Oracle and just play around Data types (try to create a datatype for timestamp or else edit the existing one)and give TIMESTAMP(%L).
May be you can find a solution.
All the Best.:)

Similar Messages

Timestamp in Data Store defaults to Logical Length of 13

I inserted a data store in designer, the table has fields that are TIMESTAMP(6) WITH TIMEZONE
The Data Store column Logical Length defaults to 13.
The execution fails with ORA-30088 because the temp table ddl is TIMESTAMP(13) WITH TIMEZONE
I fixed the issue by changing the 13 to 6 on each column.
What I want to know is how can I change the default to 6?
Or why is ODI not picking it up properly?
Is there a fix for this?

Hi,
Goto Topology ------> Physical architecture-----> Oracle ----> expand data types and edit TIMESTAMP WITH TIME ZONE
See if the following are specified against "Create Table Syntax" and " Writable Datatype Syntax"
TIMESTAMP(%L) WITH TIME ZONE
if yes , then edit the same and remove (%L) from it .
i.e. it will become TIMESTAMP WITH TIME ZONE
Save it and execute your interface .
Thanks,
Sutirtha

ODI Datastore Length differs with the DB length -IKM throws value too large

ODI datastore when reverse engineered shows different length to that of the datalength in the actual db.
ODI Datastore column details: char(44)
Target db column : varchar2(11 char)
The I$ table inserts char44 into varchar2(11char) in the target. As the source column value is empty ODI throws
"ORA-12899: value too large for column (actual: 44, maximum: 11).

Yes. I have reverse engineered the target also.
source datatype varchar2(11 char)
After Reverse Engineering
odi datstore datatype-Source : char(44)
target datatype: varchar2(11 char)
after Reverse Engineering
odi datstore datatype-Target : char(44)
Since the target datastore is char(44) in ODI Datastore and the values in the source column are null/spaces, the IKM inserts them into the target Column which is of 11 Char and the above mentioned value too large error occurs.
There are no junk values seen on the column and I tried with substr(column,1,7) and
Trim functions too and it does not help.

Physical vs Logical length issues

I am importing a fixed field flat file, and the file has a line with a special character in it. The datastore column in question is set to have a physical and logical length of 40 but ODI is erroring out saying the actual value is 41 characters. If I increase the logical length to 41 characters, but leave physical alone, the interface successfully loads the file to my relational destination.
Have I introduced any potential issues down the line by having my logical length greater than my physical length?

I think you changed the physical to 41 and leaving the logical to be 40.
I dont think you will cause any issues down the lane.
This concept is very valid in situations where you would have multi-byte characters which will physically take more bytes to load even though the logical length is less

ODBC errors while retrieving timestamp column

Hi,
I created 2 views selecting timestamp column of table ULTBPM_CCHK.CC_APPINFO:
CREATE OR REPLACE FORCE VIEW "ULTBPM_CCHK"."ERKANDENE_V" ("CCAI_RECORDDATETIME") AS select TO_DATE(TO_CHAR(CCAI_RECORDDATETIME,'DD/MM/YYYY hh24:mi:ss'),'DD/MM/YYY
Y hh24:mi:ss') CCAI_RECORDDATETIME from ULTBPM_CCHK.CC_APPINFO;
CREATE OR REPLACE VIEW "ULTBPM_CCHK"."ERKANDENE_V2"
"CCAI_RECORDDATETIME") AS select CCAI_RECORDDATETIME from ULTBPM_CCHK.CC_APPINFO;
While i can query "ULTBPM_CCHK"."ERKANDENE_V" without any problem, following errror occurs for "ULTBPM_CCHK"."ERKANDENE_V2":
SELECT AL1.CCAI_RECORDDATETIME FROM ULTBPM_CCHK.ERKANDENE_V2 AL1
ODBC Error: SQL API: [SQLBindCol], SQL RETURN: [-1], SQL STATE: [HY003], SQL NATIVE ERROR: [0], SQL MESSAGE: [[Microsoft][ODBC Driver Manager] Program type out of range]
I want to select timestamp colum, Any sugestions?
Hyperion Reporting Studio 9.3.1
Oracle 9i clent
Oracle 10g (10.2.0.4) database
Regards,
Erkan Saka

Hi,
This time it gives "ORA-03106: fatal two-task communication protocol error". I searched metalink and fould that this may be caused by incompatible SqlNet libraries or NLS settings between cklient and server. I checked NLS settings but did not solved the problem. In dbgprint file i saw that hyperion identified timestamp column (B) as ColType 0. Is it normal for timestamp column? Because when i look at the column properties in Reporting Studio, i see nothing in Item Type.
SELECT DISTINCT COLUMN_NAME, '*', COLUMN_ID, DATA_TYPE, DATA_LENGTH,
     DATA_SCALE, DATA_PRECISION, NULLABLE, '*' FROM SYS.ALL_TAB_COLUMNS
     WHERE TABLE_NAME = 'ERKAN_DENE' AND OWNER = 'DISBANK' ORDER BY
     COLUMN_ID
Server Column Information
ColName ColNum ColType Length Places Digits Nulls
======= ====== ======== ====== ====== ====== =====
A 1 NUMBER 22 0 10 0
B 2 TIMESTAMP(6) 11 6 10 1
End Select
DaMgr DMTable Column Information
ColName ColNum ColType Length Places
======= ====== ====== ====== ======
A 0 4 22 0
B 1 0 11 6
Begin Executing Document OnPreProcess Script.
End Executing Document OnPreProcess Script.
Begin Select
(0 0 )
Sending SQL to the Server:
SELECT AL1.B FROM DISBANK.ERKAN_DENE AL1
Oracle error -1 3106: ORA-03106: fatal two-task communication protocol error
Exception thrown in v1_bi_code\bl\da\dasnet_l.cpp, line 959: Oracle Error -1: ORA-03106: fatal two-task communication protocol error
DaSession::CancelOk()
Regards,
Erkan

Problem fetching multiple values in a TIMESTAMP column

Hi all,
I'm having a problem trying to fetch multiple values in a TIMESTAMP column. I can successfully fetch the TIMESTAMP column if I do the following:
OCIDateTime tstmpltz = (OCIDateTime )NULL;
rc = OCIDescriptorAlloc(p_env,(dvoid **)&tstmpltz, OCI_DTYPE_TIMESTAMP,
0, (dvoid **)0);
rc = OCIDefineByPos(p_sql, &p_dfn, p_err, 1, &tstmpltz, sizeof(tstmpltz),
SQLT_TIMESTAMP, 0, 0, 0, OCI_DEFAULT);
This works fine. I can then do what I want with the OCIDateTime variable tstmpltz, like convert it to a text string, etc.
But what I am trying to do is fetch many rows of data that could include a TIMESTAMP column. For character columns this is no problem. I simply allocate a buffer of the correct width and length and then do my OCIDefineByPos to point to the start and the character data gets filled in. Same for numeric columns as well.
I can do this with a TIMESTAMP column if I do the OCIDefineByPos with a column type of SQLT_CHR. But the problem I'm running into when I do things this way is if I fetch a Timestamp value that is before 1950 I believe it is, I get back the wrong century. So for instance 1900 comes back as 2000. I think this is because the default date format when fetching is a 2 digit year. So I've tried to the do following:
long fetchrows = 50;
unsigned char *descpp1;
descpp1 = (unsigned char *)calloc(fetchrows, sizeof (OCIDateTime *));
int i;
for (i = 0; i != fetchrows; i++)
/* Allocate descriptors */
rc = OCIDescriptorAlloc((void *)p_env,(void **)&descpp1[i * sizeof (OCIDateTime *)], OCI_DTYPE_TIMESTAMP,
0,(void **)0);
// Bind the column
rc = OCIDefineByPos(p_sql, &p_dfn, p_err, 1, descpp1, sizeof(descpp1),
SQLT_TIMESTAMP, 0, 0, 0, OCI_DEFAULT);
rc = OCIStmtExecute(p_svc, p_sql, p_err, (ub4) 50, (ub4) 0,
(CONST OCISnapshot *) NULL, (OCISnapshot *) NULL,
OCI_DEFAULT);
And I get an "ORA-01403: no data found" error. I'm missing something here but I can't figure out what it is. Is this proper way to fetch multiple Timestamp columns ?
Thanks,
Nick

Hi Nick,
I think the "trick" here is that when you call OCIDescriptorAlloc normally you would pass a pointer to an OCIDateTime pointer (i.e. OCIDateTime**). However, you're being sneaky here and using unsigned char * with malloc/calloc for the reasons you have already mentioned. So, that changes things a bit because in this scenario the "destination address" where OCI is going to put the address for the OCIDateTime descriptor is in the memory you have dynamically allocated rather than in the target pointer of an OCIDateTime** declaration. So far so good, but the problem, as you've discovered, comes about when you need to get the OCIDateTime* to pass into the OCIDateTimeToText function. In your call you have this:
(OCIDateTime *)descpp1[0 * sizeof (OCIDateTime *)]However, that isn't the address of the descriptor it's a pointer to the address so, depending on your actual calls, etc. you'll either get a memory violation or an invalid OCI handle error. What you can do is get the address from that memory location and stuff it into a proper OCIDateTime* and then it can be used in the OCIDateTimeToText function.
I'm probably doing a terrible job explaining it, but I have cobbled together a sample which does what you want (at least as far as I can tell). Of course, being OCI, there's a fair bit of code, but here's the main parts.
I created a table called "ts_test" that has the following structure and sample data:
SQL> desc ts_test
Name             Null?    Type
TS_ID                     NUMBER
TS_VALUE                  TIMESTAMP(3)
SQL> select * from ts_test order by ts_id;
     TS_ID TS_VALUE
         1 01-JAN-09 08.00.00.123 AM
         2 01-JAN-09 12.34.56.789 PM
         3 01-JAN-09 04.46.00.046 PM
         4 01-JAN-09 10.00.00.314 PM
4 rows selected.I use the same query as above in the OCI sample code to get the values back out of the table.
** will hold pointers to TimeStamp Descriptor memory
unsigned char *pTSD = (unsigned char *) NULL;
** temp pointer used with descriptors
OCIDateTime *pTemp = NULL;
** allocate memory for the ts_id column
if ((pID_val = (ub4 *) malloc(sizeof(ub4) * arrsize)) == NULL)
    printf("Failed to allocate memory for pID_val!\n");
    return;
** allocate memory for the ts descriptors
if ((pTSD = (unsigned char *) malloc(sizeof(unsigned char *) * arrsize)) == NULL)
    printf("Failed to allocate memory for pTSD!\n");
    return;
** allocate date time descriptors
for (i = 0; i < arrsize; i++)
    rc = OCIDescriptorAlloc(pDBCtx->envhp,
                            (void **) &pTSD[i * sizeof(OCIDateTime *)],
                            (ub4) OCI_DTYPE_TIMESTAMP,
                            (size_t) 0,
                            (void **) 0);
** define the first column in the results
rc = OCIDefineByPos(stmtp,
                      &defnp,
                      pDBCtx->errhp,
                      (ub4) 1,
                      (void *) pID_val,
                      (sword) sizeof(ub4),
                      (ub2) SQLT_INT,
                      (void *) pID_ind,
                      (ub2 *) 0,
                      (ub2 *) 0,
                      (ub4) OCI_DEFAULT);
** define the second column in the results
rc = OCIDefineByPos(stmtp,
                      &defnp,
                      pDBCtx->errhp,
                      (ub4) 2,
                      (void *) &pTSD[0],
                      (sword) sizeof(OCIDateTime *),
                      (ub2) SQLT_TIMESTAMP,
                      (void *) pTS_ind,
                      (ub2 *) 0,
                      (ub2 *) 0,
                      (ub4) OCI_DEFAULT);
** execute the statement
rc = OCIStmtExecute(pDBCtx->svchp,
                      stmtp,
                      pDBCtx->errhp,
                      (ub4) arrsize,
                      (ub4) 0,
                      (CONST OCISnapshot *) NULL,
                      (OCISnapshot *) NULL,
                      (ub4) OCI_DEFAULT);
** get the text value of the timestamp
** null-terminate it, and display the value.
** the address of the allocated descriptor
** is copied from the dynamically allocated
** memory to the temp variable and that
** is passed to OCIDateTimeToText
for (i = 0; i < arrsize; i++)
    memcpy((void *) &pTemp, &pTSD[i * sizeof(OCIDateTime *)], sizeof(OCIDateTime *));
    rc = OCIDateTimeToText((void *) pDBCtx->usrhp,
                           pDBCtx->errhp,
                           pTemp,
                           (oratext *) 0,
                           (ub1) 0,
                           (ub1) 3,
                           (oratext *) 0,
                           (size_t) 0,
                           &buflen,
                           buf);
    buf[buflen] = '\0';
    printf("Timestamp value[%d]: %s\n", *pID_val++, buf);
...Obviously there's lots left out, but hopefully that can be of some help. I've not really thoroughly reviewed the code so there may be a few things to fix. Anyway, using the above table and data the full sample outputs this on my system:
Timestamp value[1]: 01-JAN-09 08.00.00.123 AM
Timestamp value[2]: 01-JAN-09 12.34.56.789 PM
Timestamp value[3]: 01-JAN-09 04.46.00.046 PM
Timestamp value[4]: 01-JAN-09 10.00.00.314 PM
ENTER to continue...Thanks,
Mark

Error when reversing settlement back to Auc - Balance in transaction curren

Hi,
We get following error when reversing a settlement from asset back to Auc (using AIST):
FI/CO interface : Balance in transaction currency
Message No. RW022
This error only occurs when we settle a portion of the amount sitting in AuC and not the full amount. (When we settle full amount in AuC to final asset we can reverse no problem).
When we do a partial settlement to final asset, SAP creates a document and in that document it posts a debit and credit for the unsettled amount e.g. 50k in Auc and we settle 45k to final asset with 5k remaining in Auc - the document looks as follows
AuC     5,000.00-
Auc      5,000.00
AuC    45,000.00
Final Asset    25,000.00-
Final Asset    20,000.00-
The 5k above is the unsettled amount still sitting in AuC
When we try reverse we get error message RW022 and detail is as follows:
    The balances in transaction currency must be zero for each logical
    transaction when transferring to the FI/CO interface. A balance of "
    5,000.00-" "CAD" was determined for the logical transaction "AZVZ".
System Response
    The FI/CO interface does not process any transactions which have a
    balance in transaction currency other than zero.
Procedure
    This is a system error of the calling application.
Note: We do use line item settlement in asset classes
Much appreciate any help..

Hello,
You may need to check SAP notes below regarding this issue:
1523814   Transaction AIST ends with error RW 022
1514384   Error message RW 022 after Note 1444750 implem
1444750   Postings without transaction currency
I hope it helps.

ORDER BY timestamp column as a string

Does any one have any tips/tricks for using an ORDER BY clause for a timestamp column that is a string?
I am developing a UNION query that combines data from a table and an audit history table to show current data plus historical data.
I had to convert the timestamp column to a string so the datatypes would match for the UNION query, but now they ORDER BY clause does not work.
For example:
SELECT
location,
'CURRENT' as VALID_DATE
FROM
person
UNION
SELECT
location,
TO_CHAR(audit_date)
FROM
person_audit
ORDER BY 2 DESC

Hi,
user2269823 wrote:
Using the 'yyyy-mm-dd' format works pretty well when ordering by the string. It looks like when ordering by a string Oracle just looks at the characters sequentially.
For example:
2009-1-14
2008-12-31
2007-6-6Looks like you have changed the format slightly?
Consider this
SQL> select TO_CHAR(sysdate,'FMyyyy-mm-dd')
, TO_CHAR(sysdate, 'yyyy-mm-dd') from dual;
TO_CHAR(SY TO_CHAR(SY
2009-5-28 2009-05-28
SQL>Looks fine with me, as long as you don't have the FM format model modifer.
Regards
Peter

SSDT tries to alter timestamp column in TFS build

We're trying to perform an upgrade test against a copy (backup/restore) of our customer database as target. There are some tables with timestamp column in the database. The way we do this is by having a database project with a publish profile targeting
that copy of customer database and then with TFS build server is used to build the database but only to generate a publish script (/p:UpdateDatabase=False) set in the build definition - msbuild argument.
Example of table definition:
CREATE TABLE dbo.CodeTable1
(ID INT IDENTITY(1,1) NOT NULL PRIMARY KEY
,Code CHAR(6)
,[Timestamp] TIMESTAMP NULL);
We would like to have the "Code" column to have CHAR(7), so in the project we modify the table definition:
CREATE TABLE dbo.CodeTable1
(ID INT IDENTITY(1,1) NOT NULL PRIMARY KEY
,Code CHAR(7)
,[Timestamp] TIMESTAMP NULL);
Expecting SSDT build will generate alter script:
ALTER TABLE dbo.CodeTable1 ALTER COLUMN Code CHAR(7);
To our surprise the generated script was:
ALTER TABLE dbo.CodeTable1 ALTER COLUMN Code CHAR(7);
ALTER TABLE dbo.CodeTable1 ALTER COLUMN [Timestamp] TIMESTAMP NULL;
Which will cause error when the script is executed: "Cannot alter column 'TIMESTAMP' to be data type timestamp."
Why is SSDT generating the change script for that timestamp column??
We then try a local build in VS, the issue is not happening, SSDT correctly generates alter script only for the "Code" column to CHAR(7);
Both local machine and TFS Build server are having VS 2013 Update 4- SSDT 12.0.50318.0 installed.
As we tried to troubleshoot further, we found out that it seems it only happens on a restored database from a backup copy of our customer database. It doesn't happen for databases created by SSDT build from scratch or that we manually created. We've tried make
sure all database properties are the same as the database that correctly built. But still if the target database is the one we restored from a customer's copy, SSDT always tries to alter timestamp column (on server build).
Anyone have same experience?
I have posted a bug in ms connect: https://connect.microsoft.com/SQLServer/feedback/details/1266051
Thanks!

Thanks Paul!
However, it doesn't happen when I build the database project locally or if the target database was created by SSDT (or manually for that matter). The issue happens when I change the target database to the one we restored from a backup copy of our customer's
database and run the build through our TFS build server.
So I thought there must be something different with the restored database (which causes SSDT to alter timestamp column) as opposed to the one SSDT/manually created (which doesn't alter the timestamp column). Maybe there is difference on database property/settings?
Whatever it is, I just couldn't find it.
The only thing we will do now as workaround is to get db schema creation script from that of customer's database and run that script to re-create the database from scratch and use that as target database instead, as luck would have it, the issue would be
gone.
Still, why the heck SSDT tries to alter timestamp column in that specific case and not in other case as described above??
Elvin

Compare date datatype against timestamp column

Hi,
I have a table "test" with a TIMESTAMP column as "insert_timestamp".
I have an application with a query like
select * from test where insert_timestamp between i_start_date and i_end_date;i_start_date and i_end_date are DATE data type variables.
When I ran this query, it returned results:
select * from test where insert_timestamp between sysdate - 1 and sysdate;My question is if it is ok to compare against a TIMESTAMP column in table using DATE data type variables?.
I am just making sure the app doesn't break during execution due to this.
Thanks in advance

yes you can use...
But with timestamp you get precision till fraction of seconds but not in case of data type...
So if you have data which differ in fraction of seconds like
1.0001 sec,1.0003 sec,1.0004 sec,1.0005 sec,1.0006 sec...
then if i have to get data between 1.0003 and 1.0005 seconds you cannot use a date variable here...
Ravi Kumar

Internal error with timestamp columns

Hi
i have a table in which there's a TIMESTAMP column whenever i try to create a form on this table i cannot choose the columns in form builder data block wizard.
Or even when i try to modify a form which was created before the columns were added.
it generates this error.
FRM - 10095: Assertion Failed in iewbdbc_oracle_to_id, at C:myade\608\src\ie\iewbdb.c:703
i dont even have that directory on my machine!!!!
i tried this with forms9i & forms6i, same thing with both.
is it impossible to develope forms on a table having a timestamp column??? or is there another way?
Any help is REALLY apreciated.
Thanks in Advance
Regards
Tony G.

No the with timestamp types are not supported. Forms does supplort multiple timezones, but uses normal datatime fields mapping to dates in the DB. The Forms server then takes care of mapping the Client Time to the Database time and visa versa.
See: http://www.oracle.com/technology/products/forms/pdf/9inewfeatures.pdf
Section 10

Can you specify format mask for date or timestamp columns

Hi,
Recently when I'm developing a PL/SQL application, I find that any format mismatch between data in table and format mask specified in to_date/to_timestamp function will cause exceptions. However, I'd like to make my application more robust and immune to this kind of problems, and know exactly which format mask to use for exactly what columns in db table.
Is there a way in a table column to specify the format mask for date/timestamp columns such that I can know exactly what format mask to use when doing conversion? Also I don't want to depend on NLS_DATE_FORMAT specification, don't want to make a long case statement to check for every date format allowed by Oracle.
Many thanks.

As per my knowledge it can't be possible
casuse if you entered '12/11/2007' date
how oracle know that in date 12'th is the month or 11'th.
The person who entered that date will also have confusions in future.
either you have to fix one date format for your whole application (application configuration).
or you have to store the date format in other column of the table.
In case you set the date column to varchar and store all the dates without format then
in future you may face problems in future while fetching the records, searching etc.
Regards
Singh

Importing timestamp columns appears to use to_date instead of to_timestamp

I'm trying to import data (using the latest version 1.5.4 with Patch 2 applied) to an Oracle 10g database that contains timestamp columns. The input data has times with fractional (millisecond) values The data was exported using SQL Developer from a Sybase database and the timestamp format in the Excel (xls) file is YYYY-MM-DD HH24:MI:SS.FF3. When I specify this format for the TIMESTAMP columns on the import screens, the importer generates an insert statement like this:
INSERT INTO A (TMS) VALUES (to_date('2008-12-049 12:12:39.967', 'YYYY-MM-DD HH24:MI:SS.FF3'));
This command fails to execute with this error:
Error report:
SQL Error: ORA-01821: date format not recognized
01821. 00000 - "date format not recognized"
*Cause:
*Action:
I found that if to_timestamp is used instead of to_date, there is no issue inserting the row with the correct time precision. The question I have is why isn't SQL Developer using to_timestamp for importing a TIMESTAMP column, and should it?
Any advise woudl be appreciated.
Thanks

In 1.5.4 I see a bug where the "Format" field doesn't show up in the page in the import wizard, preventing the user from entering a mask when the column type is TIMESTAMP. This has been fixed in the code line under development and should be available when 2.1 gets released.
To give you a bit more detail on the confusing DATE/TIMESTAMP behaviour...
SQL Developer misrepresenting date as timestamp and vice versa stems from the behaviour of the Oracle JDBC driver. Following are the details I obtained from the JDBC team when I raised a bug("WRONG VALUE RETURNED FOR GETCOLUMNTYPE FOR DATE COLUMN ") on them:-
oracle.jdbc.mapDateToTimestamp is by default set
to true to indicate reporting DATE column as TIMESTAMP type. To turn off, pass
-Doracle.jdbc.mapDateToTimestamp=false" at the command line.
To effect this option in SQL Developer, you can add an AddVMOption -Doracle.jdbc.mapDateToTimestamp=false
A bit more history on the option:
8i and older Oracle databases did not support SQL TIMESTAMP, however Oracle
DATE contains a time component, which is an extension to the SQL standard. In
order to correctly handle the time component of Oracle DATE the 8i and
earlier drivers mapped Oracle DATE to java.sql.Timestamp. This preserved the
time component.
Oracle database 9.0.1 included support for SQL TIMESTAMP. In the process of
implementing support for SQL TIMESTAMP we changed the 9i JDBC driver to map
Oracle DATE to java.sql.Date. This was an incorrect decision since it
truncates the time component of Oracle DATE. There was also a backwards
compatibility problem trying to write java.sql.Timestamps to 8i databases.
These are separate problems but we "fixed" both under the control of a single
flag, V8Compatible. This flag was introduced in a 9.2 patch set.
By default the flag is false. When it is set to false the driver maps Oracle
DATE to java.sql.Date, losing the time component and it writes
java.sql.Timestamps to the database as SQL TIMESTAMPS. When the flag is set
to true the driver maps Oracle DATE to java.sql.Timestamp and writes
java.sql.Timestamps to the database as Oracle DATEs.
In 11.1 the V8Compatible flag was deprecated because it controlled Database
8i compatibility which is no longer supported. The additional behavior it
controlled, how SQL DATEs are handled, is controlled by a new flag,
mapDateToTimestamp. In 11.1 setting V8Compatible will just set
mapDateToTimestamp. This new flag only controls how SQL DATEs are
represented, nothing more. This flag will be supported for the foreseeable
future.
Finally, the default value for V8Compatible is false in 9i and 10g. This
means that by default the drivers incorrectly map SQL DATEs to java.sql.Date.
In 11.1 the default value of mapDateToTimestamp is true which means that by
default the drivers will correctly map SQL DATEs to java.sql.Timestamp
retaining the time information. Any customer that is currently setting
V8Compatible = true in order to get the DATE to Timestamp mapping will get
that behavior by default in 11.1. Any customer that wants the incorrect but
10g compatible DATE to java.sql.Date mapping can get that by setting
mapDateToTimestamp = false in 11.1.
About the only way to see the difference between mapDateToTimestamp settings
is to call getObject on a DATE column. If mapDateToTimestamp is true, the
default setting, the result will be a java.sql.Timestamp. If
mapDateToTimestamp is false, then getObject on a DATE column will return a
java.sql.Date.
HTH
Edited by: vasan_kps on Jun 12, 2009 2:01 PM

How to insert varchar2 value in timestamp column in table?

Hi all,
Hope doing well,
sir i am using one stored procedure and storing time in varchar2 variable in this format: 08:00:00
now i have to insert this value in timestamp column in table. how to insert this value in timestamp column?
thanks

952646 wrote:
Hi all,
Hope doing well,
sir i am using one stored procedure and storing time in varchar2 variable A "Very Bad Idea"(tm)
When you do this, there is no fundamental difference between "08:00:00" and "here's your sign".
Data should always be stored in the correct data type. For dates and times, that data type is either DATE or TIMESTAMP. Period.
in this format: 08:00:00
now i have to insert this value in timestamp column in table. how to insert this value in timestamp column?
Hopefully as remediation to the original bad design.
thanks

Max value for a TIMESTAMP column?

What is the max value for a TIMESTAMP column?
I'm using the ODP.NET provider 9.2.0.4. When i put C#'s DateTime.MaxValue (i.e. 12/31/9999 23:59:59,999) into a TIMESTAMP column, everything is ok. Retrieving this value (e.g. via SQL*Plus Worksheet) returns ora-01877 (string too long for internal buffer).
Any ideas?
Regards,
Daniel

Maybe you hit Bug 1782816 Select of TIMESTAMP gives ORA-1877 on some platforms
Product (Component)                      : SQL*Plus (SQL*Plus)
Range of versions believed to be affected: Versions >= 9.0 but < 9.2
Versions confirmed as being affected     : 9.0.1.3
Platforms affected                       : Generic (all / most platforms affected)

Timestamp column when reversed in ODI ,Logical Length increases to 11

Similar Messages

Maybe you are looking for