Frank Schimmelpfennig wrote: > > Hi, > > the "misbehaviour" of the DDL TIMESTAMP function in this effected table > seems the same as in tables effected by the SYSERROR -9999 error I > reported > on December 5th 2005. I seem to have found a funny correlation (?) between > the occurance of corrupted timstamp entries and different versions of the > dbproc generating the data rows that contain the timestamp field in > question: With an older version of the dbproc that has somewhat simpler > code the DDL TIMESTAMP function works fine; with a later version > (complexer > code due to new requirements) we face corrupted timestamp entries (missing > first byte). Both versions use the DDL TIMESTAMP function when inserting > data into the table which has unchanged DDL. > > Unfortunately I am not able to debug this by myself, but by calling the > TIMESTAMP function explicitly in the insert statement in the dbproc > (newest > version) the problem is bypassed. > > I do not know if this problem also occurs with newer MaxDB versions (we > use > v7.6.00 Build 012-123-102-632 here), but I suggest to investigate it! >
Hi, Now I see a chance of finding the problem. My own tests did never cause the problem to occur and the code-check was not successful as well. May I ask for the table/view definitions concerned and both versions of dbproc (in a private mail if you do not like to send it to the list) so that I have a chance to see what newer versions will do/to find the bug if it is in even in the newest version. Thank you Elke SAP Labs Berlin > kind regards > Frank > > > -- > MaxDB Discussion Mailing List > For list archives: http://lists.mysql.com/maxdb > To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
