Hitachi Vantara Pentaho Community Forums
Results 1 to 4 of 4

Thread: Update Step Issue

  1. #1
    Join Date
    Oct 2010
    Posts
    369

    Default Update Step Issue

    Hello Team

    Got some weird problem . I am using PDI 4.3/postgres DB and using update step to update record.

    Problem:-
    I have this column data "2017-01-31 17:00:14-08" having data type as "timestamp with time zone" and updating the table by comparing it with "2017-01-31 17:00:14" using "=" comparator.

    When i ran the process got the below exception.

    ERROR 31-01 23:33:44,210 - Update - Error in step, asking everyone to stop because of:
    ERROR 31-01 23:33:44,210 - Update - org.pentaho.di.core.exception.KettleDatabaseException:
    Entry to update with following key could not be found: [2017-01-31 17:00:14]


    at org.pentaho.di.trans.steps.update.Update.lookupValues(Update.java:133)
    at org.pentaho.di.trans.steps.update.Update.processRow(Update.java:327)
    at org.pentaho.di.trans.step.RunThread.run(RunThread.java:50)
    at java.lang.Thread.run(Unknown Source)


    INFO 31-01 23:33:44,211 - Update - Finished processing (I=1, O=0, R=1, W=0, U=0, E=1)

    We have 10 servers and out of 10 only 1 server is having this issue. Table structure/code is same .Any one find this issue with Update step

  2. #2
    Join Date
    Jan 2015
    Posts
    107

    Default

    Does that one failing server have a different timezone configured for 1) the server 2) the database 3) the user 4) the session?

    I'm not sure how PostGres handles dates, but I've seen Oracle and MySQL both perform implicit conversions with Timestamp (w/ timezone) fields to store them in the server's timezone.

    Client-originating settings may also affect how the incoming date is interpreted. We had mysterious timestamp entries in one website database for a long time, until we found out one piece of code was polluting the pooled connections with "ALTER SESSION" statements in order to get month names in a different language. Other processes inheriting the connections would obliviously store their timestamps and get them converted to UTC based on the alternate timezone/region.
    Last edited by Isha Lamboo; 02-01-2017 at 08:33 AM.

  3. #3
    Join Date
    Oct 2010
    Posts
    369

    Default

    Dates information comes from table column.

  4. #4
    Join Date
    Oct 2010
    Posts
    369

    Default

    Some how thats the problem found after long struggle. POstgres DB current timestamp and system time both are different which causes the problem.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Privacy Policy | Legal Notices | Safe Harbor Privacy Policy

Copyright © 2005 - 2019 Hitachi Vantara Corporation. All Rights Reserved.