This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Created attachment 102306 [details] Column data type in the original table: timestamp Steps to reproduce: 1) Create a user in the SQL editor (create user /jim/ with rights on the default tablespace users) 2) Grant user the rights to connect and create table - also in the SQL editor. 3) Log in under this user 4) Grab the structure of the Employees sample table hr DB - hr.employees 5) Recreate the table structure in user's personal schema 6) Populate the table with the data by using the sql script for inserting data. - Select all records in the hr.employees and choose Show sql script for INSERT. - Find and replace INSERT INTO hr.employees into <username>.employees. - Run the script And the error is displayed: ORA-01843: not a valid month In the original hr.employees table, the hire_date has the TIMESTAMP data type. But when the structure was grabbed, and added to the user's schema, hire_date turned into the OTHER data type That is why using a script created by NB does not work for populating the recreated table.
Created attachment 102307 [details] Column data type in the recreated table: other Added the second attachment
Thanks Irina, I'll look on it.
> 6) Populate the table with the data by using the sql script for inserting data. > - Select all records in the hr.employees and choose Show sql script for > INSERT. > - Find and replace INSERT INTO hr.employees into <username>.employees. > - Run the script > And the error is displayed: ORA-01843: not a valid month The default TIMESTAMP pattern of the database does not correspond to timestamp values in the script. You can add this command to the beginning of the script: alter session set NLS_TIMESTAMP_FORMAT='YYYY-MM-DD HH24:MI:SS.FF1'; > In the original hr.employees table, the hire_date has the TIMESTAMP data > type. > But when the structure was grabbed, and added to the user's schema, > hire_date turned into the OTHER data type It seems to work fine in the current dev version, TIMESTAMP type was exported correctly. Please reopen if you encounter some problems in recent releases.