Timestamp Datatype invalid in Oracle9i

I tried to set a column to timestamp datatype in 9i but it returns invalid datatype
Can anyone tell me why is this happen?
I used the following statement
create table test (modified timestamp);

No, TIMESTAMP is not supported in Forms. However, a fix is forthcoming to address problems with the Builder's Wizards improper handling of unsupported datatypes such as this one.
Ref._
Bug 2567564
Bug 8836073

Similar Messages

How to obtain a number of seconds between 2 fields in TimeStamp datatypa

Hello, I need to have the result of a difference between 2 fields (date1 - date2)which are in TimeStamp datatype
The result given must be in seconds
I am using owb 10.2.1.0.31
Can so help me ?
Thanks

check the Puget Sound Oracle Users Group page (http://www.psoug.org/) at
http://www.psoug.org/reference/timestamp.html
And more information on the INTERVAL DAY TO SECOND datatype at
http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/sql_elements001.htm#SQLRF00207
here's an excerpt from the PSOUG page:
CREATE TABLE tint_test (
msg VARCHAR2(25),
start_date TIMESTAMP WITH TIME ZONE,
end_date TIMESTAMP WITH TIME ZONE,
duration_1 INTERVAL DAY(5) TO SECOND,
duration_2 INTERVAL YEAR TO MONTH);
INSERT INTO tint_test
(msg, start_date, end_date)
VALUES
('my plane ride',
timestamp'2004-08-08 17:02:32.212 US/Eastern',
timestamp'2004-08-08 19:10:12.235 US/Pacific');
UPDATE tint_test
SET duration_1 = (end_date - start_date) DAY(5) TO SECOND,
duration_2 = (end_date - start_date) YEAR TO MONTH;
SELECT msg, duration_1, duration_2 FROM tint_test;
SELECT t.*, end_date - start_date FROM tint_test t;

Timestamp datatype not output correctly in table export

When using the data export from table view timestamp datatype is not handled correctly. It shows as oracle.sql.TIMESTAMP@14c0761.
Works fine from SQL Explorer view though.

Im using the same build. 1.0.0.15.27.
You can try any export option. I tried SQL Insert.
If you right click from the data grid (SQL Worksheet or Table view it works fine)
In the table view, if you go to Actions -> Export -> SQL Insert then it doesn't.

TIMESTAMP datatype in Oracle 8i.

'TIMESTAMP' datatype is not to be available in Oracle 8i.
Is there an equivalent datatype in Oracle 8i as 'TIMESTAMP' in 9i?
Regards,
Bhagat

Timestamp was a new globalization feature in 9i. The only way to handle time in 8i is with the regular DATE type and traditional date arithmetics.

Timestamp datatype issue in Expression

Hi
I am extracting data from oracle table which timestamp datatype for one column then connected to Expression operator. When i see the data type of timestamp in sourcetable it is timestamp(3), But when i see the data type of timestamp in Expression operator it says timestamp(3) but it is adding 6 in the precision by default and that cannot be changed. I tried creating new column in expression it behaved the same. there by my mapping is giving me the warnings regarding this.
Could you guys please help on this.
Thanks

Hi Cezar,
Thanks for your quick reply.
I am currently doing the second step you have mentioned. I even went to the extent of cutomizing the I$ tables getting created with a custom structure to avoid this. But this is very tedious as i have hundreds of columns in the table.
Is this a bug in ODI? I am asking this because this is a general functionality and should be ideally covered by such a good ELT tool.
I have raised a SR for the same, let us see what solution they have in store:)
Anyway thanks for your valuable suggestion its really useful.
But I have a doubt regarding the versions. Whats the difference between versions 10.1.3.2.0 which I am using and 10.1.3.4.0? I hope this version is not creating this issue?
Thanks,
Vikram

ORACLE TIMESTAMP DataType support in Toplink ?

Currently we have an application that need to create timestamps with precision up to thousands of a second.
Do you know of any other customer that have similar requirements and how they solve this problem ?
We try changing the SQL DDL to change datatype from DATE to TIMESTAMP(3) which can support a timestamp of 1/1000 seconds precision.
We find that if our Oracle column is defined as Oracle DATE, the last 3 digit will be drop and cause us some duplicate key exception for records that
Get inserted within 1 second because the timestamp is part of the primary key.
ts '2004-03-12 17:13:27.792'
So we change the ORACLE column from DATE to TIMESTAMP(3)
What we find is that Toplink produce this exception
Exception [TOPLINK-3001] (OracleAS TopLink - 10g (9.0.4) (Build 031126)): oracle.toplink.exceptions.ConversionException
Exception Description: The object [oracle.sql.TIMESTAMP@321b5e39], of class [class oracle.sql.TIMESTAMP], could not be converted to [class java.util.Date].
at oracle.toplink.exceptions.ConversionException.couldNotBeConverted(ConversionException.java:35)
at oracle.toplink.internal.helper.ConversionManager.convertObjectToUtilDate(ConversionManager.java:679)
at oracle.toplink.internal.helper.ConversionManager.convertObject(ConversionManager.java:97)
at oracle.toplink.internal.databaseaccess.DatabasePlatform.convertObject(DatabasePlatform.java:55
Than we try to change our java code and modify the java instance variable type from java.util.Date to java.sql.Timestamp
And we get the following error
Exception [TOPLINK-3001] (OracleAS TopLink - 10g (9.0.4) (Build 031126)): oracle.toplink.exceptions.ConversionException
Exception Description: The object [oracle.sql.TIMESTAMP@731de027], of class [class oracle.sql.TIMESTAMP], could not be converted to [class java.sql.Timestamp].
at org.apache.xerces.impl.XMLNamespaceBinder.endElement(XMLNamespaceBinder.java:650)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1011)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1564)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:335)
We cannot seems to find in toplink mapping workbench how to specify timestamp
========================================================================================================
The TIMESTAMP Datatype
The new TIMESTAMP datatype is almost identical to DATE and differs in only one way:
TIMESTAMPs can represent fractional seconds.
The granularity of a TIMESTAMP value can be as little as a billionth of a second, whereas
DATE variables can only resolve time to the second.
When you declare a TIMESTAMP variable, you can optionally specify the precision that you wish to use for fractional seconds. The default precision is to the millisecond (six decimal digits); the maximum precision is to the billionth of a second (nine decimal digits).
===========================================================================================================
-----Original Message-----
From: Cheung, Ka-Kit
Sent: Friday, March 12, 2004 6:20 PM
To: Burr, Tim; Julian, Robert; Matthiesen, Sean
Cc: Tsounis, George; Del Rosso, Peter; Cham, Mei
Subject: Problem identified : AddressDetail duplicate key problem
If we look at the exact of the insert statement.
We see that the last address detail insert have key of
Address ID = '5a052407-dac6-42ad-bbbf-29edc94488c1', and
TransactionStartDate = {ts '2004-03-12 17:13:27.792'},
While in the database, we look like we have an entry of
Address ID = '5a052407-dac6-42ad-bbbf-29edc94488c1', and
TransactionStartDate = {ts '2004-03-12 17:13:27.229'},
If my memory served me right, while
{ts '2004-03-12 17:13:27.792'}, is different than {ts '2004-03-12 17:13:27.229'},
because are Java timestamps that have precison up to MicroSeconds, therefore 229 is different than 792.
However, when this timestamp is saved to Oracle, I believe (have to check with Mei) that oracle only takes
Up to '2004-03-12 17:13:27 and discard the 229 or 792 because that is the maximum precision of timestamp for oracle.
So we have the second insert have the same '2004-03-12 17:13:27 after stripping off the 792 and we have a same record with the same same '2004-03-12 17:13:27 in the database and
Therefore causing duplicate key exception.
That is why this is happen only once in a while when 2 rapid fire inserts happen in less than 1 second of each other.
The solution actually is in the ESS code itselfs.
The current ESS code will send addDependentToClient multiple times, one for each dependent added
On the screen.
The right way is to add all the dependent on the screen all at once.
To have course grain method like addDependentsToClient, and have a collection or array of dependents as input parameter.
This way we are not causing the participant to create history of themselves multiple times within a very short period of time. It save disk space, conform to a single UOW per submit and that is what I proposed
To solve this problem from the root cause is by enhancing the method to save multiple dependents in one shot rather than a loop of multiple calls.
KK
and
INSERT INTO PTTCBSI.ADDRESS_DETAIL
(LINE_3_AD, ADR_TRAN_UNTIL_DT, MODIFY_DT, CITY_NM, POSTAL_CD, VER_ID, POSTAL_EXT_CD, LINE_2_AD, ADR_TRAN_START_DT, CREATE_DT, AUTHOR_ID, ADDRESS_ID, LINE_1_AD, COUNTY_NM, LINE_4_AD, COUNTRY_ID, STATE_ID)
VALUES ('Block 5, Apt. 6', {ts '9999-12-31 00:00:00.0'},
{ts '2004-03-12 17:13:26.385'},
'Oakwood', '61043', 1, '1234', 'Mailstop 820',
{ts '2004-03-12 17:13:26.385'},
{ts '2004-03-12 16:50:12.0'}, 'dataLoad',
'5a052407-dac6-42ad-bbbf-29edc94488c1',
'IBM Corp.', NULL, '140 Main Street', 'US', 'NJ')
UnitOfWork(1238222885)--Connection(2102560837)--
UPDATE PTTCBSI.ADDRESS_DETAIL
SET ADR_TRAN_UNTIL_DT = {ts '2004-03-12 17:13:26.385'}, VER_ID = 2 WHERE
(((ADDRESS_ID = '5a052407-dac6-42ad-bbbf-29edc94488c1') AND
(ADR_TRAN_START_DT = {ts '2004-03-12 16:52:29.0'})) AND (VER_ID = 1))
UPDATE PTTCBSI.ADDRESS_DETAIL SET
ADR_TRAN_UNTIL_DT = {ts '2004-03-12 17:13:27.229'}, VER_ID = 2
WHERE (((ADDRESS_ID = '5a052407-dac6-42ad-bbbf-29edc94488c1') AND (ADR_TRAN_START_DT = {ts '2004-03-12 17:13:26.0'})) AND (VER_ID = 1))
UnitOfWork(102762535)--Connection(2102560837)--
INSERT INTO PTTCBSI.ADDRESS_DETAIL
(LINE_3_AD, ADR_TRAN_UNTIL_DT, MODIFY_DT, CITY_NM, POSTAL_CD, VER_ID, POSTAL_EXT_CD, LINE_2_AD, ADR_TRAN_START_DT, CREATE_DT, AUTHOR_ID, ADDRESS_ID, LINE_1_AD, COUNTY_NM, LINE_4_AD, COUNTRY_ID, STATE_ID) VALUES
('Block 5, Apt. 6', {ts '9999-12-31 00:00:00.0'}, {ts '2004-03-12 17:13:27.229'}, 'Oakwood', '61043', 1, '1234', 'Mailstop 820',
{ts '2004-03-12 17:13:27.229'},
{ts '2004-03-12 16:50:12.0'}, 'dataLoad',
'5a052407-dac6-42ad-bbbf-29edc94488c1',
'IBM Corp.', NULL, '140 Main Street', 'US', 'NJ')
INSERT INTO PTTCBSI.ADDRESS_DETAIL
(LINE_3_AD,
ADR_TRAN_UNTIL_DT,
MODIFY_DT,
CITY_NM, POSTAL_CD, VER_ID, POSTAL_EXT_CD, LINE_2_AD,
ADR_TRAN_START_DT,
CREATE_DT,
AUTHOR_ID,
ADDRESS_ID,
LINE_1_AD, COUNTY_NM, LINE_4_AD, COUNTRY_ID, STATE_ID) VALUES
('Block 5, Apt. 6', {ts '9999-12-31 00:00:00.0'},
{ts '2004-03-12 17:13:27.792'},
'Oakwood', '61043', 1, '1234',
'Mailstop 820',
{ts '2004-03-12 17:13:27.792'},
{ts '2004-03-12 16:50:12.0'},
'dataLoad',
'5a052407-dac6-42ad-bbbf-29edc94488c1',
'IBM Corp.', NULL, '140 Main Street', 'US', 'NJ')
ClientSession(790235177)--Connection(2102560837)--rollback transaction
ORA-00001: unique constraint (PTTCBSI.PK_ADDRESS_DETAIL) violated

KK,
We are back-porting the support for oracle.sql.TIMESTAMP to 9.0.4 in an upcoming patch-set. It is possible to enhance TopLink using a customer conversion manager or database platform to add this support if required in the short term.
Doug

Capturing EDT/EST timezone with TIMESTAMP datatype

Hi guys,
In 9i DB, I need to capture date and timestamp with EDT or EST time zone specifiers. For testing pursposes, I wrote the following code and the result is as:
SET SERVEROUT ON
DECLARE
v_date TIMESTAMP WITH LOCAL TIME ZONE;
BEGIN
v_date := TIMESTAMP '2003-06-15 12:16:30 US/Eastern EDT';
DBMS_OUTPUT.PUT_LINE(v_date);
END;
I get the following result:
15-JUN-03 12.16.30.000000 PM
Actually I need 15-JUN-03 12.16.30.000000 PM EDT or EST depending on the daylight times in the Eastern coast. Also, I did change my SESSION with ALTER SESSION SET TIME_ZONE='US/Eastern' but still I do not get the promising output. I just put it to the forum in the hope if someone could help me out with the new timestamp datatype in this case please.
Any help will highly be appreciated.
Thanks
Zahir

WE need to set the NLS_TIMESTAMP_TZ_FORMAT and give apropriate format when printing timestamp:
SQL> alter session set nls_timestamp_tz_format = 'DD-MON-YYYY HH24:MI:SS TZD' ;
Session altered.
SQL> DECLARE
2     v_date TIMESTAMP WITH LOCAL TIME ZONE;
3 BEGIN
4     v_date := TIMESTAMP '2003-&1-15 12:16:30 US/Eastern';
5     DBMS_OUTPUT.PUT_LINE(TO_CHAR(v_date, 'DD-MON-YYYY HH:MI:SS TZD'));
6 END;
7 /
Enter value for 1: 01
old   4:        v_date := TIMESTAMP '2003-&1-15 12:16:30 US/Eastern';
new   4:        v_date := TIMESTAMP '2003-01-15 12:16:30 US/Eastern';
15-JAN-2003 01:16:30
PL/SQL procedure successfully completed.
SQL> /
Enter value for 1: 06
old   4:        v_date := TIMESTAMP '2003-&1-15 12:16:30 US/Eastern';
new   4:        v_date := TIMESTAMP '2003-06-15 12:16:30 US/Eastern';
15-JUN-2003 12:16:30
PL/SQL procedure successfully completed.
SQL>When I enter a date in January, it prints the time as 01:16:30 (even though the time specified in the value was 12:16:30).
And, next when I enter a date in June, it prints the time as 12:16:30 (this is what we entered).

Conversion from DATE to TIMESTAMP datatype

Hello,
My issue is as follows:
1. I have one variable of type DATE, which I assign the value of SYSDATE
mydatevar DATE:= SYSDATE;2. I want to find *"today"*, truncated to DAY
TRUNC (mydatevar, 'DD')
TRUNC function returns DATE datatype. So I will receive in point 2 for example *'2010-01-13 00:00:00'*.
3. I want to assign the value from point 2 to a variable of type TIMESTAMP
mytimestampvar TIMESTAMP := mydatevar;which implicitly will convert the DATE variable to TIMESTAMP.
Problem: During the conversion (both implicit and explicit conversion with a format mask) I lose the "00" hours and "00" minutes and receive something like this: "10-JAN-13 *12*.00.00.000000000 AM".
Question: How can I convert from DATE to TIMESTAMP keeping hours and minutes zeros?
Why I need this conversion: I have a table with a column "column1" TIMESTAMP(0) and I would like to take only those rows from the table, where "column1" is in range from today 12 o'clock in the morning till now (whatever hour it is).
NLS characteristics of the database:
PARAMETER                           VALUE
NLS_LANGUAGE                           AMERICAN
NLS_TERRITORY                   AMERICA
NLS_CURRENCY     $
NLS_ISO_CURRENCY                    AMERICA
NLS_NUMERIC_CHARACTERS     .,
NLS_CHARACTERSET                    AL32UTF8
NLS_CALENDAR                            GREGORIAN
NLS_DATE_FORMAT                    DD-MON-RR
NLS_DATE_LANGUAGE            AMERICAN
NLS_SORT     BINARY
NLS_TIME_FORMAT                     HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT             DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT             HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT     DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY              $
NLS_COMP                             BINARY
NLS_LENGTH_SEMANTICS              BYTE
NLS_NCHAR_CONV_EXCP             FALSE
NLS_NCHAR_CHARACTERSET     AL16UTF16
NLS_RDBMS_VERSION             10.2.0.4.0Session parameters are the same.
DBTIMEZONE is "+02:00".

Verdi wrote:
Problem: During the conversion (both implicit and explicit conversion with a format mask) I lose the "00" hours and "00" minutes and receive something like this: "10-JAN-13 *12*.00.00.000000000 AM".I don't think you are necessarily losing any information whatsoever. It's probably more of a function of your NLS_TIMESTAMP_FORMAT and NLS_DATE_FORMAT. For example your NLS_DATE_FORMAT could be setup by default for a HH24 (24 hour time) which would report midnight as "00" hours. However, it looks like your NLS_TIMESTAMP_FORMAT is setup with a "HH" format with a meridian indicator which means 12 hours time.
Your comparisons should be using date/timestamp data types anyways so as long as the input value is converted properly into a date type this shouldn't matter anyways.
You can see what is actually stored by using the DUMP function:
SQL> SELECT DUMP(TO_TIMESTAMP(TO_CHAR(TRUNC(SYSDATE,'DD'),'MM/DD/YYYY HH:MI:SS AM'))) AS TSTAMP
2 ,       DUMP(TRUNC(SYSDATE,'DD')) AS DT
3 FROM DUAL
4 /
TSTAMP                                                                      DT
Typ=187 Len=20: 218,7,1,13,0,0,0,0,0,0,0,0,0,0,3,0,0,0,0,0                  Typ=13 Len=8: 218,7,1,13,0,0,0,0As you can see the TSTAMP and DT store nearly the same values (218,7,1,13), but the TSTAMP has more precision because of fractional seconds.
HTH!
Edited by: Centinul on Jan 13, 2010 7:23 AM

IR group by function and timestamp datatype

Is there any limitations on the group by function e.g. based on the datatype.
My problem\misunderstanding is with the IR:
USING "GROUP BY"-
I have a TIMESTAMP column (columnname TM_TIME) and I can schose it in the group by clause but not in the function section. Is there any reason why and could I get it to work.
regards
Thorsten
Edited by: Fischert on 02.05.2012 03:05

It really depends on the granularity that you need from the timestamp to make it meaningful. The key word is aggregation. So you should ask what level of aggregation do I need?
You can reduce the granularity from the fractional seconds to some lower level of granularity like seconds, minute, hours or even date (equivalent of trunc(date_column) using CAST or Truncating or to_date(to_char(...)) with appropriate format mask.
It just depends on the application and data.
E.g. for the LHC at CERN chasing the Higgins, timestamp is just not fine grained enough (you need 10 exp -23 or lower I guess !)
E.g. if you look at seismic data for oil exploration a hell of a lot happens in 5th and 6th decimal places in the timestamp.
But if you are looking at data logged by a normal SCADA system then maybe a second is detailed enough for the purpose.
In normal business application we are better off "rounding" the timestamp to some meaningful level for aggregation/ reporting.
Regards,

Timestamp Datatype

Hi Gurus,
I have column (datatype-timestamp) in physical layer but as when i am checking in user interface found only date is displaying
Any clue regarding to this
thanks

Hi Gurus,
I viewd the data in the physical layer it shows in date,time,miliseconds
datatype is also timestamp.when i am casting it shows the data but without casting onlyn dates are coming
it shows some gap(blanck space) after the date
thanks
Edited by: user1124854 on Nov 10, 2010 6:33 AM

SQL Developer 3.2 - Exporting data with TIMESTAMP datatype

Hi,
We have users that are attempting to export data with the Timestamp format to Excel (xls format) using SQL Developer 3.2. When attempting to sort the Timestamp in either asc or desc order, Excel is having issues sorting correctly. I suggested that the user just do all the sorting within their SQL Developer session but they require the ability to slice and dice in Excel.
This is definitely not an issue with Excel as the users have previously exported Timestamp data from Toad and been able to sort without issue. Any thoughts as to what might resolve this issue?
Thanks.

We're not formatting timestamps in Oracle as numbers/dates in Excel. They'll need to properly format the Excel column/cells to get it to sort the way they want vs being treated as simple strings.

Using TRUNC in timestamps

Sir,
As you know we were using TRUNC function in DATE datatype. But I want to use it with TIMESTAMP datatypes. For example:
select trunc(systimestamp,'hh24:mi:ss') from dual;
The main idea to get some part of given timestamp without using type conversions (i.e. TO_CHAR).
Note that this is useful when you want to ADD or Subtract the time side from timestamp with interval values and comparing them to another timestamps fields or values.
Thank you in advance.

Trunc is not working in 9i
Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production
SQL> SELECT current_timestamp - TRUNC (current_timestamp) time
2 FROM dual
3 /
SELECT current_timestamp - TRUNC (current_timestamp) time
ERROR at line 1:
ORA-00932: inconsistent datatypes: expected NUMBER got TIMESTAMP
SQL>
But in 10g...
Personal Oracle Database 10g Release 10.1.0.2.0 - Production
With the Partitioning, OLAP and Data Mining options
SQL> SELECT current_timestamp - TRUNC (current_timestamp) time
2 FROM dual;
TIME
+000000000 14:53:04.941000
SQL>
Why?

TIMESTAMP Error

I get the following error :
ERROR at line 2:
ORA-01843: not a valid month
when I try to insert in a timestamp : '2000-03-23 10:13:54'
I have looked at TIMESTAMP format and it is set to : YYYY-MM-DD HH24:MI:SS
I am using Oracle 9i.
Is there a command I could use that would return what format my database is expecting for TIMESTAMP.
Thanks Tony

This is how you would do the parameter change (for DATE and TIMESTAMP datatypes), if not using explicit conversion, as shown in above examples:
SQL> create table t (a date, b timestamp) ;
Table created.
SQL> insert into t values ('2000-03-23 10:13:54', '2000-03-23 10:13:54') ;
insert into t values ('2000-03-23 10:13:54', '2000-03-23 10:13:54')
ERROR at line 1:
ORA-01861: literal does not match format string
SQL> alter session set nls_date_format = 'yyyy-mm-dd hh24:mi:ss' ;
Session altered.
SQL> insert into t values ('2000-03-23 10:13:54', '2000-03-23 10:13:54') ;
insert into t values ('2000-03-23 10:13:54', '2000-03-23 10:13:54')
ERROR at line 1:
ORA-01843: not a valid month
SQL> alter session set nls_timestamp_format = 'yyyy-mm-dd hh24:mi:ss' ;
Session altered.
SQL> insert into t values ('2000-03-23 10:13:54', '2000-03-23 10:13:54') ;
1 row created.
SQL>

How can I create an index on the date part of a timestamp field?

is there a way I can create an index on the date part of a timestamp field?

LONGENECKER wrote:
Idea:
If you find no direct command that allows you to create an index on JUST the date portion of a timestamp datatype column then I recommend you consider splitting date and time into two seperate columns.
If date is column "A" and time is column "B" then you can concatenate them using a view or virtual column (in 11G) to re-assemble them at run time.
In the solution I describe above you might trade ease of management for better performing queries.
Additional Info:
This thread may be of some value.
Can we create INDEX on TIMESTAMP column???
And what datatype do you propose for your columns A and B? The only proper datatypes would be DATE or TIMESTAMP. Both of these inherently carry both date and time components, so that would have to be dealt with anyway. The use of any character or number datatype to hold date and/or time should be treated with an application of Billy's lead pipe.
Perhaps function based indexes would be a better solution.

Change indicator via trigger (Date/Timestamp)

I have set up triggers on all my tables to update the 'TIME_STAMP' field whenever a change is made to the row. It works flawlessly in sql*plus as well as in TOAD. However,if I insert a record using a ADF client I can view the record and the trigger provided value using sql*plus. If I update it using the ADF client the data becomes corrupted. I get a "ORA-01877: string is too long for internal buffer" when trying to view it with sql*plus or TOAD and if I dump() the column I get "Typ=180 Len=11: 0,0,0,0,0,0,0,0,0,0,0" (note: this is a dump when I had reset the datatype in my table and entity to a DATE).
The xml file for my entity follows:
Any Ideas?????
<?xml version='1.0' encoding='windows-1252' ?>
<!DOCTYPE Entity SYSTEM "jbo_03_01.dtd">
<Entity
Name="WbsUsers"
DBObjectType="synonym"
DBObjectName="WBS_USERS"
AliasName="WbsUsers"
BindingStyle="Oracle"
UseGlueCode="false"
RowClass="wbs.model.entity.WbsUsersImpl"
CollClass="wbs.framework.entity.EntityObjectCollImpl"
MsgBundleClass="wbs.model.entity.common.WbsUsersImplMsgBundle" >
<DesignTime>
<Attr Name="_isCodegen" Value="true" />
<Attr Name="_version" Value="10.1.2.17.96" />
<Attr Name="_codeGenFlag2" Value="Init|Access|Msg" />
<Attr Name="_superClass" Value="wbs.framework.entity.EntityObjectImpl" />
<Attr Name="_collSuperClass" Value="wbs.framework.entity.EntityObjectCollImpl" />
<AttrArray Name="_publishEvents">
</AttrArray>
</DesignTime>
<Attribute
Name="Id"
IsUpdateable="false"
Precision="32"
ColumnName="ID"
Type="java.lang.String"
ColumnType="CHAR"
SQLType="CHAR"
TableName="WBS_USERS"
PrimaryKey="true"
RetrievedOnUpdate="true"
RetrievedOnInsert="true" >
<DesignTime>
<Attr Name="_DisplaySize" Value="32" />
</DesignTime>
</Attribute>
<Attribute
Name="Username"
IsNotNull="true"
Precision="30"
ColumnName="USERNAME"
Type="java.lang.String"
ColumnType="VARCHAR2"
SQLType="VARCHAR"
TableName="WBS_USERS"
RetrievedOnUpdate="true"
RetrievedOnInsert="true" >
<DesignTime>
<Attr Name="_DisplaySize" Value="30" />
</DesignTime>
</Attribute>
<Attribute
Name="Fname"
IsNotNull="true"
Precision="50"
ColumnName="FNAME"
Type="java.lang.String"
ColumnType="VARCHAR2"
SQLType="VARCHAR"
TableName="WBS_USERS"
RetrievedOnUpdate="true"
RetrievedOnInsert="true" >
<DesignTime>
<Attr Name="_DisplaySize" Value="50" />
</DesignTime>
</Attribute>
<Attribute
Name="Lname"
IsNotNull="true"
Precision="50"
ColumnName="LNAME"
Type="java.lang.String"
ColumnType="VARCHAR2"
SQLType="VARCHAR"
TableName="WBS_USERS"
RetrievedOnUpdate="true"
RetrievedOnInsert="true" >
<DesignTime>
<Attr Name="_DisplaySize" Value="50" />
</DesignTime>
</Attribute>
<Attribute
Name="WbsRoleId"
IsNotNull="true"
Precision="32"
ColumnName="WBS_ROLE_ID"
Type="java.lang.String"
ColumnType="CHAR"
SQLType="CHAR"
TableName="WBS_USERS"
RetrievedOnUpdate="true"
RetrievedOnInsert="true" >
<DesignTime>
<Attr Name="_DisplaySize" Value="32" />
</DesignTime>
</Attribute>
<Attribute
Name="Email"
IsNotNull="true"
Precision="255"
ColumnName="EMAIL"
Domain="wbs.model.entity.emailDomain"
Type="wbs.model.entity.common.emailDomain"
ColumnType="VARCHAR2"
SQLType="VARCHAR"
TableName="WBS_USERS"
RetrievedOnUpdate="true"
RetrievedOnInsert="true" >
<DesignTime>
<Attr Name="_DisplaySize" Value="100" />
</DesignTime>
</Attribute>
<Attribute
Name="TimeStamp"
IsUpdateable="false"
ColumnName="TIME_STAMP"
Type="oracle.jbo.domain.Date"
ColumnType="DATE"
SQLType="TIMESTAMP"
TableName="WBS_USERS"
ChangeIndicator="true"
RetrievedOnUpdate="true"
RetrievedOnInsert="true" >
<DesignTime>
<Attr Name="_DisplaySize" Value="11" />
</DesignTime>
</Attribute>
<AccessorAttribute
Name="WbsRoles"
Association="wbs.model.entity.WbsUserRoleFkAssoc"
AssociationEnd="wbs.model.entity.WbsUserRoleFkAssoc.WbsRoles"
AssociationOtherEnd="wbs.model.entity.WbsUserRoleFkAssoc.WbsUsers"
Type="wbs.model.entity.WbsRolesImpl" >
</AccessorAttribute>
<AccessorAttribute
Name="WbsUserPeriods"
Association="wbs.model.entity.WbsUpUFkAssoc"
AssociationEnd="wbs.model.entity.WbsUpUFkAssoc.WbsUserPeriods"
AssociationOtherEnd="wbs.model.entity.WbsUpUFkAssoc.WbsUsers"
Type="oracle.jbo.RowIterator"
IsUpdateable="false" >
</AccessorAttribute>
<Key
Name="SysC0012735" >
<AttrArray Name="Attributes">
<Item Value="wbs.model.entity.WbsUsers.Id" />
</AttrArray>
<DesignTime>
<Attr Name="_DBObjectName" Value="SYS_C0012735" />
<Attr Name="_checkCondition" Value=""ID" IS NOT NULL" />
<Attr Name="_isCheck" Value="true" />
</DesignTime>
</Key>
<Key
Name="SysC0012736" >
<AttrArray Name="Attributes">
<Item Value="wbs.model.entity.WbsUsers.Username" />
</AttrArray>
<DesignTime>
<Attr Name="_DBObjectName" Value="SYS_C0012736" />
<Attr Name="_checkCondition" Value=""USERNAME" IS NOT NULL" />
<Attr Name="_isCheck" Value="true" />
</DesignTime>
</Key>
<Key
Name="SysC0012737" >
<AttrArray Name="Attributes">
<Item Value="wbs.model.entity.WbsUsers.Fname" />
</AttrArray>
<DesignTime>
<Attr Name="_DBObjectName" Value="SYS_C0012737" />
<Attr Name="_checkCondition" Value=""FNAME" IS NOT NULL" />
<Attr Name="_isCheck" Value="true" />
</DesignTime>
</Key>
<Key
Name="SysC0012738" >
<AttrArray Name="Attributes">
<Item Value="wbs.model.entity.WbsUsers.Lname" />
</AttrArray>
<DesignTime>
<Attr Name="_DBObjectName" Value="SYS_C0012738" />
<Attr Name="_checkCondition" Value=""LNAME" IS NOT NULL" />
<Attr Name="_isCheck" Value="true" />
</DesignTime>
</Key>
<Key
Name="SysC0012739" >
<AttrArray Name="Attributes">
<Item Value="wbs.model.entity.WbsUsers.WbsRoleId" />
</AttrArray>
<DesignTime>
<Attr Name="_DBObjectName" Value="SYS_C0012739" />
<Attr Name="_checkCondition" Value=""WBS_ROLE_ID" IS NOT NULL" />
<Attr Name="_isCheck" Value="true" />
</DesignTime>
</Key>
<Key
Name="SysC0012740" >
<AttrArray Name="Attributes">
<Item Value="wbs.model.entity.WbsUsers.Email" />
</AttrArray>
<DesignTime>
<Attr Name="_DBObjectName" Value="SYS_C0012740" />
<Attr Name="_checkCondition" Value=""EMAIL" IS NOT NULL" />
<Attr Name="_isCheck" Value="true" />
</DesignTime>
</Key>
<Key
Name="SysC0012741" >
<AttrArray Name="Attributes">
<Item Value="wbs.model.entity.WbsUsers.TimeStamp" />
</AttrArray>
<DesignTime>
<Attr Name="_DBObjectName" Value="SYS_C0012741" />
<Attr Name="_checkCondition" Value=""TIME_STAMP" IS NOT NULL" />
<Attr Name="_isCheck" Value="true" />
</DesignTime>
</Key>
<Key
Name="WbsUsersEmailCheck" >
<AttrArray Name="Attributes">
<Item Value="wbs.model.entity.WbsUsers.Email" />
</AttrArray>
<DesignTime>
<Attr Name="_DBObjectName" Value="WBS_USERS_EMAIL_CHECK" />
<Attr Name="_checkCondition" Value=""EMAIL" IS NOT NULL" />
<Attr Name="_isNotNull" Value="true" />
<Attr Name="_isCheck" Value="true" />
</DesignTime>
</Key>
<Key
Name="WbsUsersPk" >
<AttrArray Name="Attributes">
<Item Value="wbs.model.entity.WbsUsers.Id" />
</AttrArray>
<DesignTime>
<Attr Name="_DBObjectName" Value="WBS_USERS_PK" />
<Attr Name="_isPrimary" Value="true" />
<Attr Name="_isDeferrableConstraint" Value="true" />
<Attr Name="_isInitiallyDeferredConstraint" Value="true" />
</DesignTime>
</Key>
<Key
Name="WbsUserRoleFk" >
<AttrArray Name="Attributes">
<Item Value="wbs.model.entity.WbsUsers.WbsRoleId" />
</AttrArray>
<DesignTime>
<Attr Name="_DBObjectName" Value="WBS_USER_ROLE_FK" />
<Attr Name="_referencedKey" Value="WBS_ROLES_PK" />
<Attr Name="_isForeign" Value="true" />
<Attr Name="_isDeferrableConstraint" Value="true" />
<Attr Name="_isInitiallyDeferredConstraint" Value="true" />
</DesignTime>
</Key>
</Entity>

Hi all,
I am a dope. I was having so may problems with the TIMESTAMP datatype in ADF and in TOAD I decided to just go with a DATE datatype for a change indicator. I did all the changes in the build scripts and model but forgot to run the build script so the errors I was getting were based on the old datatype.
BTW, Steve Muench had published a workaround to the issue in October that I found after I did all my changes. (http://radio.weblogs.com/0118231/2004/10/07.html#a394)

Timestamp Datatype invalid in Oracle9i

Similar Messages

Maybe you are looking for