• [Info-ingres] E_DM9387_INDEX_UPDATE_ERROR because of II_TIMEZONE_NAME

    From Adrian Williamson@21:1/5 to All on Mon Jul 26 22:15:09 2021

    I've this OR6.2 program that deletes data from an Ingres 11 database on the same Windows 2012 R2 host.

    As Ingres 11 and OR6.2 don't (or did not ) play nice (Ingres Net issues as far as I recall) they are on separate installations on the host.

    For a very specific multi-row (28 rows) delete that looks like this:

    Delete from relevant_date where case_id = 700431

    The OpenROAD (and the SQL prompt using the same OR6.2 vnode) causes this error when deleting a record:

    E_DM0056_NOPART NOPART Btree error.
    E_DM9385_NO_INDEX_TUPLE Cannot locate secondary index row for base table row at TID 15373.
    E_DM9386_SEC_INDEX_ERROR Error updating secondary index ,relevant_date_idx, for change to base table row at TID 15373.
    E_DM9387_INDEX_UPDATE_ERROR Update failed due to inability to update secondary index table.

    The relevant_date_idx is a secondary index on a date column in the relevant_date table.

    In the OR6.2 installation the II_TIMEZONE_NAME was set to GMT and in Ingres 11 UNITED-KINGDOM

    Setting the OR6.2 to UNITED_KINGDOM makes it all work.

    The row in question under GMT gives the index column date as '21/10/1999 00:00:00' but under UNITED-KINGDOM looks like '21/10/1999 01:00:00'.

    I settle for working, understanding is a luxury that few of my clients are willing to pay for.

    But there is a part of me that thinks - "Is that by design that it looks to compare the key values and the TID/TIDP when deleting from the primary table?"

    I figured that this is some kind of adult stuff that us kiddies just don’t get.




    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)