UC_UTILITY_REORG > MELD 'unread' setting not respected
Article ID: 443281
Updated On:
Products
Issue/Introduction
The DB-Reorg Utility is using incorrect reorganization specifications for MELD, causing it to reorganize and delete significantly more records than intended in the case when the values for unread messages is set lower than than for read messages.
For instance if you set the following: UC_UTILITY_REORG > MELD = TRUE 0006 0002
Setting the 'unseen' (days2) lower than the 'seen' (day1), the setting is not respected and all MELD record are reorganized with the 'unseen' (lowest) retention delay.
When tracing the ucybdbre program (db=4), the problem is demonstrated:
The data from UC_UTILITY_REORG is read correctly:
20260522/091153.870 - Messages (MELD): read: '6' days ('2026.05.16') unread: '2' days ('2026.05.20')
20260522/091153.870 - Statistics (AH): '2' days ('2026.05.20') Keep last 1 Statistical records per object
20260522/091153.870 - Reports (RH/RT): '1' days ('2026.05.21') Keep last 1 Reports per object
20260522/091153.871 - Version Management: '30' days ('2026.04.22') Keep last 10 VC per objectSubsequently, the number of to be deleted entries is correctly counted for read and unread:
read:
20260522/091153.872 - >2026.05.15 22:00:00.0<
20260522/091153.872 - SELECT COUNT(*) DIVDB_INT4 FROM MELD WHERE MELD_Client = ? and MELD_Seen = 1 and Meld_DeleteFlag = 0 AND MELD_TimeStamp < ?
20260522/091153.872 - U00029179 PGSQRY: 'PGSQuery::ExecuteX(BEGIN)'
20260522/091153.873 - UCUDB32 SLUC RET 0000 HSTMT: 0x00000033df2880 VALUE: 0x00000033df2880 ALL: 0.00085 DB: 0.00076 ODBC: 0.00000 UDB: 0.00009
20260522/091153.873 - U00009909 TRACE: (DB-DATEN: DIVDB_Int4 ) 0x7ff73bb5cfec 000004
00000000 01000000 >....<
20260522/091153.873 - >1<
unread:
20260522/091153.873 - >2026.05.19 00:00:00.0<
20260522/091153.873 - SELECT COUNT(*) DIVDB_INT4 FROM MELD WHERE MELD_Client = ? and MELD_Seen = 0 and Meld_DeleteFlag = 0 AND MELD_TimeStamp < ?
20260522/091153.873 - U00029179 PGSQRY: 'PGSQuery::ExecuteX(BEGIN)'
20260522/091153.873 - UCUDB32 SLUC RET 0000 HSTMT: 0x00000033df2880 VALUE: 0x00000033df2880 ALL: 0.00032 DB: 0.00023 ODBC: 0.00000 UDB: 0.00009
20260522/091153.873 - U00009909 TRACE: (DB-DATEN: DIVDB_Int4 ) 0x7ff73bb5cfec 000004
00000000 02000000 >....<
20260522/091153.873 - >2<
But the subsequently the SELECT of the records to be deleted uses the wrong date for the unread:
read:
20260522/091153.874 - >2026.05.19 00:00:00.0< --- same as below
20260522/091153.874 - Select Meld_Idnr from MELD WHERE MELD_Client = ? and Meld_DeleteFlag = 0 and MELD_Seen = 1 and MELD_TimeStamp < ?
20260522/091153.874 - U00029179 PGSQRY: 'PGSQuery::ExecuteX(BEGIN)'
20260522/091153.874 - UCUDB32 SLUC RET 0000 HSTMT: 0x00000033df2880 VALUE: 0x00000033df2880 ALL: 0.00039 DB: 0.00031 ODBC: 0.00000 UDB: 0.00008
unread:
20260522/091153.878 - >2026.05.19 00:00:00.0<
20260522/091153.878 - Select Meld_Idnr from MELD WHERE MELD_Client = ? and MELD_Seen = 0 and Meld_DeleteFlag = 0 and MELD_TimeStamp < ?
20260522/091153.878 - U00029179 PGSQRY: 'PGSQuery::ExecuteX(BEGIN)'
20260522/091153.878 - UCUDB32 SLUC RET 0000 HSTMT: 0x00000033df2880 VALUE: 0x00000033df2880 ALL: 0.00042 DB: 0.00027 ODBC: 0.00000 UDB: 0.00015
Cause
DE202242
Resolution
This will be fixed in a future version of the DB Reorg Utility.
For the moment, it is recommended to set day1 and day2 to an identical date.
Feedback
