Frank Schimmelpfennig wrote > > Hello, > > I faced a SYSERROR -9999 on a MaxDB 7.6 instance (7.6.00 Build > 012-123-102-632 on Windows Server 2003 Std.Edt. SP1) when I tried to > update > a record in a user table: > > UPDATE calling_modules > SET ver_id = (SELECT ver_id FROM snr_versions WHERE release_no = > '1.3.2') > WHERE module_name = 'SNR_PUT_INCREMENT' > // > > or > > UPDATE calling_modules > SET ver_id = 6 > WHERE module_name = 'SNR_PUT_INCREMENT' > // > > or > > UPDATE calling_modules > SET ver_id = 6 > WHERE mod_id = 16 > // > > All three variants of the SQL statement led to the same error message.Here > are the knldiag.err entries: > > 2005-12-05 16:18:19 0xA74 ERR 51080 SYSERROR -9999 Otherwise unknown > errorcode > 2005-12-05 16:18:19 0xA74 ERR 51080 SYSERROR -9999 Otherwise unknown > errorcode > 2005-12-05 16:20:09 0xA74 ERR 51080 SYSERROR -9999 Otherwise unknown > errorcode > > Is there someone who has an idea what is going on? > > Thanks in advance! > > kind regards > Frank >
After several mails sent directly incl. vtrace and the table and trigger-definition involved it can be said: For some (unknown) reason the column create_date in table calling_modules is not stored as it should be. There is one leading byte missing. If one selects this table directly, this should be visible (or resulting an error). When the above update is called, a trigger is fired trying to select something using the expression CHAR(:OLD.create_date) . Then it is known, that the current-value of :OLD.create_date should be a timestamp. This is checked. And according to the missing leading byte, this check does not succeed. This kind of error should never occur and is handled as internal error (not given a well-known external message number, but this funny -9999). Unfortunately I do not know which version of kernel was used in September, when the wrong data was included and which statement/client was used for it. And I do not remember/did not find the description of any bug resulting in such an effect. This means two things: the data in THIS database/table has to be changed, otherwise different errors will occur when using this column. This (perhaps) can be done by selecting the column with chr(create_date) . I expect a missing '2' in the beginning. This could be added with something like this : update .. create_date = '2' || chr(create_date). This means on the other hand, that the same table in another database, filled with the same values may or may not be correct (because filled with another kernel-version/client/statement). This has to be checked with a simple select * for this table. Unfortunately, if the table is not filled at one specific day, with one kernel version / client / statement, then a correct first resultrow does NOT mean that all of them are correct. Sorry for the inconveniences caused. Nevertheless, please have a nice weekend. Elke SAP Labs berlin > > -- > 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]
