Since you don't provide any details about your setup, or what you're doing it's hard to say. See How do I post a question effectively?. A google search for the error you posted returns this. DBD::ODBC documents problems with Oracle dates. If this isn't the issue you are experiencing you will have to make some more effort when asking for help.

Following on from what marto said.

Format your question better - see code tags, in the formatting help as some of the error message you posted contained square brackets which have a special meaning here.

Describe exactly what you changed to cause this problem - you say "After oracle 10g driver upgrading script" - what does that mean?

Tell us exactly which driver you are using - I can see it is probably Oracle's ODBC driver but what are the versions before and after upgrade and what platform is this?

As you appear to be inserting a date what is the type of the column you are inserting into and what did the date look like?

Thanks for reply,

More details about issue:

I have a perl script that was working fine until I upgraded my Oracle client 9i to 10g (instant client). I'm inserting data into an Oracle database via DBD-ODBC.

We found this error from logs:

 Monday, August 12, 2013 4:33 PM
Product Group ID = 4
Count = 2Last extract to date: 080108131644,  extract to date : 090130
+095622 , Current run id: 55 
Errstr = 
Exception Found - Error_ID 12
[download]

While updating the records in to below table failing the script.

we are assuming this issue is some thing related to date format and changed the code at script level with diffrent format of dates ,but its not much help full resolve this issue.

UPDATE TEST_CONTROL_TABLE SET PN_Date = to_date(?,'yyyymmddhh24miss'),
+ E_From_Date = to_date(?,'yyyymmddhh24miss'), E_To_Date = to_date(?,'
+yyyymmddhh24miss'), E_MN = ?, E_Sts = ?, D_R_ID = ?, D_Mode = ?, D_St
+ts = ?, H_ID = ?, keep_M = ?, Hkeep_Sts = ?, Pr_Stt = ?, E_From_Qtes 
+= ?, L_To_S_Qte = ?, Unque_Po_Count = ?, Unque_C_Count = ?, Unque_End
+or_Count = ?, Pol_F_Record_Count = ?, Cl_File_Re_Count = ?, End_Rec_C
+ount = ? WHERE R_ID = ?}; 
    my $sth8 = $dbh->prepare( $sql8 ) or error(17)
[download]

Current using ORACLE NLS date format setting is rrmmddhh24miss

with out changing NLS setting is there any options to resolve this issue?

Script connection setting information:

my $driver = "ODBC"; my $server = "localhost"; my $database = "";

Please let me know,if you require any more details.

In the original post you had the error on this record

Last extract to date: 20130211035545


and now you have an error on this record

Last extract to date: 080108131644


so it looks like you have a mixture of 2 digit and 4 digit years in your input data. If this is the case then try the SQL with to_date(?,'rrrrmmddhh24miss') as the rrrr accepts both formats.

poj

Okay, let me suggest to you that it seems very likely to me that you have a red herring problem here, because it seems very, very unlikely to me that a change to the client of a client/server system would cause an SQL insert, on the server of course, to throw a data-conversion error.   Now, perhaps this change revealed the existence of a problem that has existed for a long time ... but I frankly doubt that, too.   What seems most likely to me right now is that there is a configurable setting on the client side upon which this program depends.   The dependency might not be documented in your company’s IT logs (if you keep them), and when/who made the setting probably isn’t recorded either, but it is something that is affecting date/time conversions.   It could be an Oracle setting or it could, perhaps more likely, be a setting related to ODBC.   It probably has been reset to some kind of default.   You should look in both places, because an Oracle-client upgrade would not necessarily be known to ODBC.

Now, none of us are (nor could we be) a “code-writing service” for you, such that you can expect to toss a snippet of code at us and say, “please fix this for me.”   (That sort of thing requires a Crystal Ball, and mine’s busted.)   We are here to help, but You are going to have to do some detective work here, with regards to this software that only you know best.   Start with wherever this data originates, and trace it forward step-by-step from there, no matter where it goes and whether or not it involves Perl.   (In this case it is quite probable that it does not.)   HTH.™